XR Rel-18

RAN1#109-e

9.11 Study on XR enhancements for NR

Please refer to RP-220285 for detailed scope of the SI.

R1-2205053 Work plan for Rel-18 SI on XR enhancements for NR Qualcomm Incorporated

R1-2204673 TR 38.835 Skeleton for Study on XR enhancements for NR Rapporteur (Nokia)

[109-e-R18-XR-01] – Margarita (Nokia)

Email discussion and approval of TR skeleton for Rel-18 SI on XR enhancements for NR by May 13

R1-2205329 TR 38.835 Skeleton for Study on XR enhancements for NR Rapporteur (Nokia)

Decision: As per email decision posted on May 15^th,

Agreement

The TR skeleton for TR 38.835 Study on XR enhancements for NR (R1-2205329) is endorsed as v0.0.1 from RAN1 perspective. Send LS to RAN2 to convey this agreement.

R1-2205419 [Draft] LS on draft TR 38.835 skeleton Nokia

Decision: As per email decision posted on May 16^th, the draft LS is endorsed. Final LS is approved in R1-2205443.

9.11.1 XR specific power saving techniques

R1-2203131 Discussion on XR-specific power saving techniques Huawei, HiSilicon

Proposal 1: Further study power saving techniques to address the following XR-specific issues:

- Non-integer periodicity

- Jitter

Proposal 2: When studying the potential enhancements to address XR-specific issues, the following general principles are considered

- Principle 1: The solutions should be forward compatible, e.g., applicable to potential new frame rate in the future.

- Principle 2: Solution(s) that can address multiple or all the identified issues are more preferred.

Proposal 3: Further study the following directions for C-DRX and PDCCH monitoring enhancements to address the non-integer periodicity issue:

- Adjusting the start offset of DRX OnDuration and/or the start offset of PDCCH monitoring

- Adjusting the periodicity, e.g. configuring a cycle pattern

- Multiple C-DRX configurations

Proposal 4: Further study the following mechanisms to allow skipping unnecessary PDCCH monitoring caused by jitter:

- Configuring a PDCCH monitoring pattern within DRX OnDuration or Search Space duration to match jitter distribution;

- Skipping unnecessary PDCCH monitoring once the XR frame is received correctly;

- UE monitors PDCCH sparsely before the data arrival and monitors PDCCH densely once the data arrives, e.g., implicit SSSG switching based on data arrival.

Decision: The document is noted.

R1-2203348 Discussion on XR specific power saving techniques Spreadtrum Communications

R1-2203484 UE Power saving techniques for XR CATT

R1-2203585 Discussion on XR specific power saving enhancements vivo

R1-2203606 Discussion on XR specific power saving techniques ZTE, Sanechips

R1-2203638 Discussion on power saving enhancements for XR Ericsson

R1-2203666 Discussion on XR enhancement for NR China Telecom

R1-2203744 Considerations on power saving techniques for XR Sony

R1-2203927 Considerations on XR-specific Power Savings Samsung

R1-2203940 Discussion on XR specific power saving techniques NEC

R1-2204028 Discussion on XR specific power saving techniques OPPO

R1-2204123 Discussion on XR specific power saving enhancements InterDigital, Inc.

R1-2204177 XR specific power saving techniques TCL Communication Ltd.

R1-2204264 Views on XR specific power saving techniques Apple

R1-2204326 Discussion on XR-specific power saving techniques CMCC

R1-2204400 Discussion on XR specific power saving techniques NTT DOCOMO, INC.

R1-2204414 XR-specific power saving techniques Lenovo

R1-2204444 Discussion on XR specific power saving techniques ITRI

R1-2204633 Discussion on XR-specific power saving techniques LG Electronics

R1-2204655 Discussion on power saving techniques for XR ETRI

R1-2204674 Discussion on XR-specific power saving enhancements Nokia, Nokia Shanghai Bell

R1-2204698 On XR specific power saving techniques MediaTek Inc.

R1-2204818 Discussion on power saving enhancements for XR applications Intel Corporation

R1-2205176 Power saving techniques for XR Qualcomm Incorporated (rev of R1-2205054)

[109-e-R18-XR-02] – Huilin (Qualcomm)

Email discussion on XR power saving by May 20

- Check points: May 13, May 20

R1-2205055 Moderator Summary#1 on XR specific power saving techniques Qualcomm Incorporated

From May 13^th GTW session

Agreement:

Rel-17 evaluation methodology for XR power saving captured in TR 38.838 is used as the baseline evaluation methodology for UE power evaluation of Rel-18 SI on XR enhancements.

Agreement:

Companies are encouraged to compare performance of the following Rel-15/16/17 features with the proposed enhancements for Rel-18 XR power saving evaluations. Power saving gain is calculated w.r.t. the AlwaysOn baseline.

· Rel-15/16 CDRX including long DRX cycle, short DRX cycle and DRX command MAC CE and DCP

· Rel-17 PDCCH adaptation including PDCCH skipping and SSSG switching

Note: up to companies to report the configuration of the Rel-15/16/17 features

R1-2205410 Moderator Summary#2 on XR specific power saving techniques Moderator (Qualcomm)

R1-2205411 Moderator Summary#3 on XR specific power saving techniques Moderator (Qualcomm)

From May 19^th GTW session

Agreement:

For power saving study of Rel-18 XR SI, CDRX enhancements to evaluate in this study item are to be selected from the following:

· High priority Issue 1-1: Alignment between CDRX and XR traffic for resolving the mismatch between CDRX cycle and XR traffic periodicity for each flow

· High priority Issue 1-2: C-DRX enhancements to handle jitter

· Medium priority Issue 1-3: CDRX enhancements for multiple XR traffic flows [Note 2]

· Low priority Issue 1-4: CDRX enhancements to adjust to variable burst sizes and frame rate

o Note: Some companies think the adjustment for variable burst sizes can be realized by existing spec already

· Low priority Issue 1-5: low latency handling

· Low priority Issue 1-6: SFN wraparound mismatch (if handled in RAN1)

FFS: how the solutions or the combination of the solutions can handle all the identified issues.

Note 1: Other considerations are not precluded

Note 2: It can also be adopted for addressing issue 1-1

Note 3: Companies are encouraged to clarify or provide more details of the proposed solutions, for addressing concerns from the group.

Additional details can be found in R1-2205411.

Agreement:

For power saving study of Rel-18 XR SI, PDCCH monitoring enhancements to evaluate in this study item are to be selected from the following

· Low priority Issue 2-1: Alignment between PDCCH monitoring and XR traffic to resolve the mismatch between PDCCH monitoring periodicity and XR traffic periodicity.

o Note: some companies think Rel-17 PDCCH monitoring adaptation can solve issue 2-1 or achieve similar intended outcome

o Note: Solutions proposed for Issue 2-1 and those proposed for Issue 1-1 are motivated by the same issue, namely non-integer XR traffic periodicity. It is to be studied how they compare in in terms of power saving gain and capacity, (a) solutions proposed for Issue 1-1; (b) solutions proposed for Issue 2-1.

· Low priority Issue 2-2: XR-dedicated PDCCH monitoring window to supplement CDRX for multi-flow traffic.

o Note: some companies think Rel-17 PDCCH monitoring adaptation can solve issue 2-2 or achieve similar intended outcome

o Note: Solutions proposed for Issue 2-2 and those proposed for Issue 1-3 are motivated by the same issue, namely multiple XR traffic flows. It is to be studied how they compare in in terms of power saving gain and capacity, (a) solutions proposed for Issue 1-3; (b) solutions proposed for Issue 2-2.

· High priority Issue 2-3: Enhancements to Rel-17 PDCCH monitoring adaptation.

o Note: Discussion on some enhancements may depend on the outcome of Rel-17 PDCCH monitoring adaptation maintenance

o Note: The study on enhancement to R17 PDCCH monitoring adaptation should focus on the techniques that are used for addressing XR-specific issues, e.g., jitter

Note 1: Other considerations are not precluded

Note 2: Companies are encouraged to clarify or provide more details of the proposed solutions, for addressing concerns from the group.

Agreement:

For Rel-18 XR power saving enhancements, RAN1 further discusses by RAN1 #110 whether the issues below are to be addressed, and if so, which solutions should be selected for evaluation in this study item. These issues are low priority.

· Issue 3-1: Misaligned UE transmission and reception.

· Issue 3-2: Power saving by XR-aware scheduling.

o Note 1b: XR SI objective has XR-awareness in RAN listed as a specific topic of RAN2 study

· Issue 3-3: Unnecessary data transmission in allocated resources.

Note 1: Rel-18 XR SI objective only has CDRX enhancements and PDCCH monitoring enhancements explicitly listed as focus of RAN1 study

Note 2: Other considerations are not precluded

Decision: As per email decision posted on May 21^st,

Conclusion

· If no evaluation result is provided by any company for an issue, the issue is deprioritized. The issue and proposed enhancements for the issue will not be captured by RAN1 in TR 38.835.

· If no evaluation result is provided by the proponent company for a proposed enhancement, the proposed enhancement is deprioritized. The proposed enhancement will not be captured by RAN1 in TR 38.835.

· If multiple enhancement techniques are proposed for the same issue, there can be down selection among them for the consideration of candidate enhancement for study item recommendation by RAN1 at least based on performance (power saving and capacity), spec impact, signaling overhead and implementation complexity.

· Companies are encouraged to provide detailed information for both the proposed enhancement and the existing power saving features used as the performance reference so that the evaluation results for both can be reproduced by other companies.

· When using existing power saving features as the performance reference, companies are encouraged to configure the existing power saving features to achieve the best performance.

· For evaluation of a proposed enhancement and evaluation of the existing power saving features as performance reference, companies are encouraged to provide the high load case (as defined in TR 38.838, Section A.2) results. Results for low load case can also be reported optionally.

R1-2205412 Final Moderator Summary on XR specific power saving techniques Moderator (Qualcomm)

[109-e-R18-XR-03] – Huilin (Qualcomm)

Email discussion on incoming LS (R1-2203219) on UE Power Saving for XR and Media Services by May 18

- Email discussion to start on May 10

- Relevant tdocs: R1-2203395, R1-2203487, R1-2203591, R1-2203592, R1-2204126, R1-2204926, R1-2204969

R1-2205413 Draft Reply LS on UE Power Saving for XR and Media Services Moderator (Qualcomm)

Further revised in

R1-2205530 Draft Reply LS on UE Power Saving for XR and Media Services Moderator (Qualcomm)

Decision from May 19^th GTW session: The draft reply LS to SA2 is endorsed with the following correction

· PDU set size (number of bits) or number of PDUs in a PDU set: RAN1’s understanding is that in comparison to the statistical information, real-time or dynamic information provided to gNB, if possible, can help scheduler make more efficient scheduling decision to enable UE power saving.

Final LS is approved in

R1-2205531 Reply LS on UE Power Saving for XR and Media Services RAN1, Qualcomm

MCC: Inform SA2/RAN2 that source still shows "Qualcomm [RAN WG1]", and should be corrected to "RAN1".

9.11.2 XR-specific capacity enhancements techniques

R1-2203065 XR Capacity Evaluation and Enhancements FUTUREWEI

R1-2203132 Discussion on XR-specific capacity enhancements techniques Huawei, HiSilicon

R1-2203349 XR capacity consideration Spreadtrum Communications

R1-2203485 NR enhancement for XR capacity improvement CATT

R1-2203586 Discussion on XR specific capacity enhancements vivo

R1-2203607 Discussion on XR specific capacity enhancements techniques ZTE, Sanechips

R1-2203639 Discussion on capacity enhancements for XR Ericsson

R1-2203689 Discussion on XR-specific capacity enhancements NEC

R1-2203745 Considerations on capacity enhancements techniques for XR Sony

R1-2203928 Considerations on XR Capacity Improvements Samsung

R1-2203934 Discussion on XR specific capacity improvement techniques Panasonic

R1-2204029 Discussion on XR specific capacity enhancements techniques OPPO

R1-2204124 Discussion on XR specific capacity enhancements InterDigital, Inc.

R1-2204129 Discussion on XR specific capacity enhancements techniques III

R1-2204178 XR-specific capacity enhancements techniques TCL Communication Ltd.

R1-2204265 Views on XR specific capacity enhancements techniques Apple

R1-2204327 Discussion on XR-specific capacity enhancements techniques CMCC

R1-2204401 Discussion on XR specific capacity improvement enhancements NTT DOCOMO, INC.

R1-2204415 XR-specific capacity enhancement techniques Lenovo

R1-2204634 Discussion on XR-specific capacity enhancement techniques LG Electronics

R1-2204656 Discussion on capacity enhancements techniques for XR ETRI

R1-2204675 Discussion on XR-specific capacity enhancements Nokia, Nokia Shanghai Bell

R1-2204699 On XR specific capacity improvement enhancements MediaTek Inc.

R1-2204759 Discussion on potential SPS enhancements for XR CEWiT

R1-2204819 Discussion on capacity enhancements for XR applications Intel Corporation

R1-2205056 Capacity enhancement techniques for XR Qualcomm Incorporated

R1-2205072 Discussion on XR-specific capacity enhancements techniques FGI

//This one is to use NWM – please use RAN1-109-e-NWM-R18-XR-04 as the document name

[109-e-R18-XR-04] – Sorour (Ericsson)

Email discussion on XR capacity enhancement by May 20

- Check points: May 13, May 20

R1-2205265 FL Summary#1 – Study on XR Specific Capacity Improvements Moderator (Ericsson)

From May 13^th GTW session

Agreement

Rel-17 evaluation methodology for XR capacity enhancement captured in TR 38.838 is used as the baseline evaluation methodology for XR capacity enhancement of Rel-18 SI on XR enhancements.

R1-2205266 FL Summary#2 – Study on XR Specific Capacity Improvements Moderator (Ericsson)

From May 17^th GTW session

Conclusion

Study of network coding for capacity enhancements during Rel-18 XR SI is down prioritized in RAN1.

R1-2205267 FL Summary#3 – Study on XR Specific Capacity Improvements Moderator (Ericsson)

From May 19^th GTW session

Agreement

· For each candidate capacity enhancement technique for XR traffic, companies are encouraged to consider the following common principle for assessment of the candidate capacity enhancement technique:

o Identify the XR-specific issue(s) that the enhancement technique is addressing

o Identify the necessity of the enhancement technique to address the issues

o Identify whether/how the enhancements provide benefit/performance capacity gain.

§ Consider at least feasibility, complexity, and system level performance evaluations in comparing the enhancement techniques. Power saving gains for a given enhancement technique can optionally be evaluated and considered in addition to these other aspects.

· The baseline scheduling scheme when comparing the proposed capacity enhancements techniques is:

o Dynamic scheduling and/or

o Semi-persistent scheduling / Configured grant scheduling

§ Note: Companies are encouraged to additionally use DG scheduling as the baseline scheduling scheme when showing the capacity performance gain

Decision: As per email decision posted on May 20^th,

Agreement

· To support a candidate capacity enhancement technique for XR traffic, capacity performance gain by the technique as compared to baseline should be shown.

o Capacity performance gain by the candidate technique as compared to baseline is a necessary condition to consider supporting the candidate technique.

Conclusion

Companies are encouraged to use the capacity Excel sheet attached with TR 38.838 in RP-213652 for recording the simulation results that are provided in their contributions.

Agreement

To study whether/how to support a candidate capacity enhancement technique for XR traffic based SPS/CG transmissions, companies are encouraged to consider the following studies:

· Study enhancements related to multiple PDSCHs SPS transmission occasions in a period

· Study enhancements related to multiple PUSCHs CG transmission occasions in a period

· Study enhancements related to dynamic adaptation of SPS/CG parameters/configurations

· Study enhancements related to non-integer periodicity for SPS/CG transmissions.

· Note: Other studies are not precluded, as well as the combination of the above studies.

Follow the common principle for assessment of the candidate capacity enhancement technique.

Agreement

To study whether/how to support a candidate capacity enhancement technique for XR traffic based dynamic scheduling/grant transmissions, companies are encouraged to consider the following studies:

· Study enhancements related to extending capability of single DCI scheduling multi-PDSCHs/PUSCHs for FR2-2 to FR1/FR2.

o Note: whether and how to discuss enhancements may depend on the outcome of Rel-17 B52.6G UE feature discussion

· Study enhancements related to HARQ-ACK and/or CBG transmissions for single DCI scheduling one or multi PDSCH(s).

· Study enhancements related to allowing different configurations per PDSCH/PUSCH

· Study enhancement related to scheduling request and/or BSR with the focus on L1 enhancements.

· Note: Other studies are not precluded as well as the combination of the above studies.

Follow the common principle for assessment of the candidate capacity enhancement technique.

Conclusion

It is common understanding that studying of RAN2 proposed techniques for XR-awareness information to improve XR capacity can be studied in RAN1 upon request from RAN2.

Agreement

The following lists the candidate enhancements techniques for link adaptation to improve XR capacity that are proposed by companies RAN1#109-e.

· At least the proponents are encouraged to justify the corresponding capacity benefits for XR traffic for considering potential study of these candidate enhancements techniques.

o Delta MCS

o Soft HARQ-ACK feedback

o Cooperative MIMO scheme via precoding technique - bi-directional training

o Enhanced link adaptation for CBG-based transmission

o CSI report enhancements to address the different BLER requirements of different XR flows

· Follow the common principle for assessment of the candidate capacity enhancement technique.

Agreement

The following lists the candidate enhancements techniques based on measurement-gap link to improve XR capacity that are proposed by companies RAN1#109-e.

· At least the proponents are encouraged to justify the corresponding capacity benefits for XR traffic for considering potential study of these candidate enhancements techniques.

o Dynamic L1 based MG activation/deactivation.

o Reuse current R16/R17 RRM relaxation condition to allow scheduling in MG to transform the R16/R17 RRM power saving gain into capacity gain.

· Follow the common principle for assessment of the candidate capacity enhancement technique.

Decision: As per email decision posted on May 21^st,

Agreement

The following lists the candidate enhancements techniques to improve XR capacity that are proposed by companies RAN1#109-e.

· At least the proponents are encouraged to justify the corresponding capacity benefits for XR traffic for considering potential study of these candidate enhancements techniques.

o Inter-UE/intra-UE multiplexing techniques, including e.g. finer granularity preemption indication

· Follow the common principle for assessment of the candidate capacity enhancement technique.

R1-2205268 FL Summary#4 – Study on XR Specific Capacity Improvements Moderator (Ericsson)

9.11.33 Other

R1-2203486 XR awareness scheduling and QoS control CATT

R1-2203587 Discussion on other aspects for XR specific RAN enhancements vivo

R1-2203608 Consideration about XR services ZTE, Sanechips

R1-2203640 Discussion on XR-Awareness Ericsson

R1-2204125 Discussion on XR-Awareness InterDigital, Inc.

R1-2204266 Considerations on enhancements for XR Apple

R1-2204635 Other aspects of XR enhancements for NR LG Electronics

R1-2204676 Performance results of XR-related enhancements Nokia, Nokia Shanghai Bell

R1-2204820 Views on XR specific RAN enhancement in QoS III

R1-2204908 Discussion on XR-specific capacity and power issues based on SA2 outcome Huawei, HiSilicon

RAN1#110

9.11 Study on XR enhancements for NR

Please refer to RP-220285 for detailed scope of the SI.

[110-R18-XR] Email to be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc – Huilin (Qualcomm)

9.11.1 XR specific power saving techniques

R1-2205843 XR specific power saving techniques TCL Communication Ltd.

R1-2205877 Discussion on XR-specific power saving techniques Huawei, HiSilicon

R1-2205916 Discussion on power saving enhancements for XR Ericsson

R1-2206007 Discussion on XR specific power saving techniques Spreadtrum Communications

R1-2207860 Discussion on XR specific power saving enhancements vivo (rev of R1-2206061)

R1-2206105 Discussion on XR power saving techniques III

R1-2206131 Considerations on power saving techniques for XR Sony

R1-2206225 XR-specific power saving enhancements Nokia, Nokia Shanghai Bell

R1-2206244 Discussion on XR specific power saving techniques NEC

R1-2206328 Discussion on XR specific power saving techniques OPPO

R1-2206384 UE Power saving techniques for XR CATT

R1-2206436 Discussion on XR specific power saving techniques Panasonic

R1-2206495 Power saving techniques for XR Rakuten Mobile, Inc

R1-2206518 XR-specific power saving techniques Lenovo

R1-2206601 Discussion on XR specific power saving techniques Intel Corporation

R1-2206629 Discussions on techniques for XR Power Saving Xiaomi

R1-2206702 Discussion on XR specific power saving enhancement for NR China Telecom

R1-2206846 Considerations on XR-specific Power Savings Samsung

R1-2206931 Discussion on XR-specific power saving techniques CMCC

R1-2206959 Discussion on power saving techniques for XR ETRI

R1-2206965 On XR-specific power saving techniques Google Inc.

R1-2207008 On XR specific power saving techniques MediaTek Inc.

R1-2207042 Discussion on XR-specific power saving techniques LG Electronics

R1-2207061 Evaluation on XR specific power saving techniques ZTE, Sanechips

R1-2207253 Power saving techniques for XR Qualcomm Incorporated

R1-2207263 Discussion on XR specific power saving techniques InterDigital, Inc.

R1-2207351 XR specific power saving techniques Apple

R1-2207426 Discussion on XR specific power saving techniques NTT DOCOMO, INC.

R1-2207831 Moderator Summary#1 on XR specific power saving techniques Moderator (Qualcomm Incorporated)

From Tuesday session

Conclusion

Conclude that “SFN wraparound mismatch” is a RAN2 issue. It can be left to RAN2 to address. RAN1 does not further study it.

Agreement

RAN1 recommends identifying a solution for enhancement of CDRX to align with XR traffic periodicity

Conclusion

RAN1 does not assume instantaneous jitter value for a frame is predictable for Rel-18 XR SI power saving study before further input is provided by SA.

R1-2207832 Moderator Summary#2 on XR specific power saving techniques Moderator (Qualcomm Incorporated)

From Wed session

Conclusion

All the proposed PDCCH monitoring adaptation/reduction schemes including those for jitter handling need to be compared against the Rel-17 PDCCH monitoring adaptation which is to be used as performance reference.

Conclusion

UE transmission and reception alignment for Issue 3-1 is deprioritized for power saving in Rel-18 XR SI.

Conclusion

RAN1 does not assume dynamic switch of different XR video data rates or frame rates for Rel-18 XR power saving study before further input is provided by SA.

R1-2207833 Final Moderator Summary on XR specific power saving techniques Moderator (Qualcomm Incorporated)

For future meetings

· Companies are encouraged to account the enhancement of CDRX to align with XR traffic periodicity in their further evaluations for XR power saving enhancements.

Conclusion:

· Companies are requested to use the Excel sheet attached with TR 38.838 in RP-213652 for recording the simulation results that are provided in their contributions.

9.11.22 XR-specific capacity enhancements techniques

R1-2205751 XR Capacity Evaluation and Enhancements FUTUREWEI

R1-2205844 XR-specific capacity enhancements techniques TCL Communication Ltd.

R1-2205878 Discussion on XR-specific capacity enhancements techniques Huawei, HiSilicon

R1-2205917 Discussion on capacity enhancements for XR Ericsson

R1-2206008 Discussion on XR specific capacity enhancements techniques Spreadtrum Communications

R1-2206132 Discussion on XR-specific capacity enhancements Sony

R1-2206226 XR-specific capacity enhancements Nokia, Nokia Shanghai Bell

R1-2206329 Discussion on XR specific capacity enhancements techniques OPPO

R1-2206385 NR enhancement for XR capacity improvement CATT

R1-2206475 Discussion on XR-specific capacity enhancements NEC

R1-2206519 XR-specific capacity enhancement techniques Lenovo

R1-2206602 Discussion on XR specific capacity enhancement techniques Intel Corporation

R1-2206703 Discussion on XR specific capacity enhancement for NR China Telecom

R1-2206847 Considerations on XR Capacity Improvements Samsung

R1-2206932 Discussion on XR-specific capacity enhancements techniques CMCC

R1-2206960 Discussion on SPS and CG enhancements for XR capacity improvement ETRI

R1-2206964 On XR-specific capacity enhancements techniques Google Inc.

R1-2207009 On XR specific capacity improvement enhancements MediaTek Inc.

R1-2207043 Discussion on XR-specific capacity enhancement techniques LG Electronics

R1-2207062 XR specific capacity enhancements ZTE, Sanechips

R1-2207077 Discussion on XR specific capacity enhancements CEWiT

R1-2207095 Discussion on XR-specific capacity enhancements techniques FGI

R1-2207254 Capacity enhancement techniques for XR Qualcomm Incorporated

R1-2207264 Discussion on XR-specific capacity enhancements techniques InterDigital, Inc.

R1-2207301 Discussion on XR-specific capacity improvements Rakuten Mobile, Inc

R1-2207352 XR-specific capacity enhancements techniques Apple

R1-2207427 Discussion on XR specific capacity improvement enhancements NTT DOCOMO, INC.

R1-2207718 Discussion on XR specific capacity enhancements vivo (rev of R1-2206062)

R1-2207820 Moderator Summary#1 - Study on XR Specific Capacity Improvements Moderator (Ericsson)

From Tuesday session

For further discussion this week

Details the performance evaluation scheduling when DG is used as baseline:

Start with delay assumption in UL, whether it should be related to SR, or both SR and BSR.

Agreement

RAN1 to make decision on the following in RAN1#110bis-e

· Support single DCI scheduling multi-PDSCHs/PUSCHs which is currently supported for FR2-2 to other SCS in FR1/FR2

R1-2207821 Moderator Summary#2 - Study on XR Specific Capacity Improvements Moderator (Ericsson)

From Wed session

Conclusion

There is no consensus in RAN1 on the benefits of enhancing SPS for the purpose of XR capacity enhancement

Agreement

When DG is used as the baseline scheme ~~to study CG enhancements to improve XR capacity performance~~, for the performance evaluation scheduling, after SR is triggered, both BSR and UL data ~~are~~ can be transmitted using the UL grant after SR.

· Companies are encouraged to provide the size of resources by the first UL grant after SR

Agreement

Whether/how to enhance BSR to improve capacity performance of XR traffic is within RAN2 scope and is not handled by RAN1.

· ~~Note that RAN1 can discuss techniques associated to enhanced BSR for CG and DG related studies RAN1~~.

· Note that companies should indicate if and what BSR enhancement is assumed in their RAN1 proposals on CG and DG enhancements.

· RAN1 can evaluate BSR enhancement to improve capacity performance

R1-2207822 Moderator Summary#3 - Study on XR Specific Capacity Improvements Moderator (Ericsson)

Agreement

· Deprioritize the study of CQI report for different BLER and/or different XR traffic to improve XR capacity performance.

Agreement

· Deprioritize the study of intra/inter UE prioritization/multiplexing enhancements to improve XR capacity performance.

For future meetings:

Companies are requested to follow the following agreement and conclusion from RAN1#109-e. Check final FL summary for details.

· Agreement

o Rel-17 evaluation methodology for XR capacity enhancement captured in TR 38.838 is used as the baseline evaluation methodology for XR capacity enhancement of Rel-18 SI on XR enhancements.

· Conclusion

o Companies are encouraged to use the capacity Excel sheet attached with TR 38.838 in RP-213652 for recording the simulation results that are provided in their contributions.

Final summary in R1-2207823.

RAN1#110-bis-e

9.10 Study on XR enhancements for NR

Please refer to RP-220285 for detailed scope of the SI.

9.10.1 XR specific power saving techniques

R1-2208952 UE Power saving techniques for XR CATT

· Proposal 1: Rel-17 PDCCH skipping adaptation should be enhanced to further reduce UE power consumption for XR services, e.g., non-scheduling DCI based PDCCH skipping.

· Proposal 2: The extension of non-scheduling DCI format design could reuse the existing DCI format 1_1 in Rel-16 and not increase the size of DCI format with additional function in extending the PDCCH monitoring adaptation in PCell without introducing additional information field.

· Proposal 3: The procedure of Rel-17 PDCCH skipping adaptation should be enhanced for delay sensitive XR service to avoid frequent skipping indication signal overhead, e.g., continuous skipping indication.

· Proposal 4: The go-to-sleep indication should be enhanced to be jointly configured with PDCCH skipping indication in the XR-specific DCI for fast transition to the sleep state PDCCH skipping enhancement schemes.

· Proposal 5: The adaptation indication for PDCCH skipping should be separately between XR and other indicated to avoid different services latency requirements.

· Proposal 6: DRX enhancement for XR service should not affect other data services.

· Proposal 7：The dynamic XR-dedicated PDCCH monitoring scheme customized the PDCCH monitoring control matching XR traffic generation and disassociate the PDCCH monitoring control by C-DRX is the feasible solution for C-DRX enhancement and does not have impact to the delay insensitive traffic arrival compared to the pre-configured non-uniform DRX cycles.

· Proposal 8: The XR-dedicated PDCCH monitoring window should be supported for XR UE power saving due to the advantages that it doesn't affect other data services and is achievable.

· Proposal 9: The SPS enhancement with PDCCH skipping and go-to-sleep should be supported for XR UE power saving.

· Proposal 10: The SPS enhancement that the pre-configured PDCCH monitoring window bundled with the reserved SPS resource for PDSCH would be provide the resource to meet the QoS requirement of XR-specific traffic with obvious power saving gain.

· Proposal 11: gNB awareness of UE playout buffer should be studied and supported for XR UE power saving.

· Proposal 12: How to reduce UL power consumption caused by UL data transmission and UL control information feedback should be studied for potential power saving gain for XR service.

· Proposal 13: Alignment between PUSCH transmission and HARQ feedback should be studied and supported to reduce UL power consumption for XR UE, e.g., single DCI indicating UL transmission and DL transmission (including HARQ feedback for DL reception) simultaneously.

Decision: The document is noted.

R1-2208401 Discussion on power saving enhancements for XR Ericsson

R1-2208420 Discussion on XR-specific power saving techniques Huawei, HiSilicon

R1-2208566 Discussion on XR specific power saving techniques Spreadtrum Communications

R1-2210273 Discussion on XR specific power saving enhancements vivo (rev of R1-2208660)

R1-2208781 Discussion on XR specific power saving enhancement for NR China Telecom

R1-2208862 Discussion on XR specific power saving techniques OPPO

R1-2208999 XR specific power saving techniques TCL Communication Ltd.

R1-2209069 Discussion on XR specific power saving techniques Intel Corporation

R1-2209112 Considerations on XR specific power saving techniques Sony

R1-2209128 XR-specific power saving techniques Lenovo

R1-2209197 Evaluation on XR specific power saving techniques ZTE, Sanechips

R1-2209263 Discussions on techniques for XR Power Saving xiaomi

R1-2209354 Discussion on XR-specific power saving techniques CMCC

R1-2209387 Discussion on XR specific power saving techniques Panasonic

R1-2209410 Discussion on power saving techniques for XR ETRI

R1-2209427 Discussion on XR specific power saving techniques NEC

R1-2209456 Discussion on XR-specific power saving techniques LG Electronics

R1-2209517 On XR specific power saving techniques MediaTek Inc.

R1-2209535 XR-specific power saving enhancements Nokia, Nokia Shanghai Bell

R1-2209597 XR specific power saving techniques Apple

R1-2209619 Power saving techniques for XR Rakuten Symphony

R1-2209636 On XR-specific power saving techniques Google Inc.

R1-2209657 Discussion on XR specific power saving techniques InterDigital, Inc.

R1-2209748 Considerations on Power Savings for XR Samsung

R1-2209919 Discussion on XR specific power saving techniques NTT DOCOMO, INC.

R1-2210002 Power saving techniques for XR Qualcomm Incorporated

R1-2210084 Further Discussion on XR power saving III

[110bis-e-R18-XR-01] – Huilin (Qualcomm)

Email discussion on XR power saving by October 19

- Check points: October 14, October 19

R1-2210337 Moderator Summary#1 on XR specific power saving techniques Moderator (Qualcomm Incorporated)

From Oct 11th GTW session

Agreement:

For enhancement of CDRX to align with XR traffic periodicity (i.e., Issue 1-1)

· Prioritize semi-static solutions

o FFS: Whether dynamic solutions will be also needed

R1-2210338 Moderator Summary#2 on XR specific power saving techniques Moderator (Qualcomm Incorporated)

Presented in Oct 17th GTW session

Decision: As per email decision posted on Oct 20th,

Conclusion

“Retransmission-less CG for UL pose transmission (Item 3.3-5)” is a RAN2 issue, leave the discussion to RAN2, RAN1 does not further investigate the issue.

· Note: how to capture evaluation results and findings will be separately discussed

Conclusion

RAN1 does not further study jitter handling by LP-WUS (Item 2.2-4) in Rel-18 XR SI

· Note: how to capture evaluation results and findings will be separately discussed

Conclusion

In addition to the values for jitter in Table 5.1-2 in TR 38.838, the following statistical parameters for jitter can also be optionally evaluated in Rel-18 XR SI.

· Note: This optional assumption is not applicable to the evaluation of 90 FPS and above

Parameter	unit	Optional value for evaluation
Mean	ms	0
STD	ms	5
Truncation range	ms	[-8, 8]

Conclusion

RAN1 deprioritizes DCP indicated SSSG switching (Item 3.3-4)

· Note: how to capture evaluation results and findings will be separately discussed

Final summary in R1-2210339.

9.10.22 XR-specific capacity enhancements techniques

R1-2208377 XR Capacity Evaluation and Enhancements FUTUREWEI

R1-2208402 Discussion on capacity enhancements for XR Ericsson

R1-2208421 Discussion on XR-specific capacity enhancements techniques Huawei, HiSilicon

R1-2208661 Discussion on XR specific capacity enhancements vivo

R1-2208782 Discussion on XR specific capacity enhancement for NR China Telecom

R1-2208863 Discussion on XR specific capacity enhancements techniques OPPO

R1-2208953 NR enhancement for XR capacity improvement CATT

R1-2209000 XR-specific capacity enhancements techniques TCL Communication Ltd.

R1-2209070 Discussion on XR specific capacity enhancement techniques Intel Corporation

R1-2209113 Considerations on XR-specific capacity enhancements Sony

R1-2209129 XR-specific Capacity Enhancement Techniques Lenovo

R1-2209156 Discussion on XR-specific capacity enhancements NEC

R1-2209198 XR specific capacity enhancements ZTE, Sanechips

R1-2209355 Discussion on XR-specific capacity enhancements techniques CMCC

R1-2209388 Discussion on XR capacity enhancement techniques Panasonic

R1-2209457 Discussion on XR-specific capacity enhancement techniques LG Electronics

R1-2209518 On XR specific capacity improvement enhancements MediaTek Inc.

R1-2209536 XR-specific capacity enhancements Nokia, Nokia Shanghai Bell

R1-2209598 XR-specific capacity enhancements techniques Apple

R1-2209620 Discussion on XR-specific capacity improvements Rakuten Symphony

R1-2209642 On XR-specific capacity enhancements techniques Google Inc.

R1-2209658 Discussion on XR-specific capacity enhancements techniques InterDigital, Inc.

R1-2209749 Considerations on Capacity Improvements for XR Samsung

R1-2209920 Discussion on XR specific capacity improvement enhancements NTT DOCOMO, INC.

R1-2210003 Capacity enhancement techniques for XR Qualcomm Incorporated

[110bis-e-R18-XR-02] – Sorour (Ericsson)

Email discussion on XR capacity enhancement by October 19

- Check points: October 14, October 19

R1-2210410 Moderator Summary#1 - Study on XR Specific Capacity Improvements Moderator (Ericsson)

R1-2210411 Moderator Summary#2 - Study on XR Specific Capacity Improvements Moderator (Ericsson)

From Oct 13th GTW session

Agreement:

To study whether/how the enhanced CG candidate techniques are necessary and beneficial for improving XR capacity, focus at least on the following techniques:

· Dynamic indication of the unused CG PUSCH occasion(s) or resource(s) by the UE

· Increase CG PUSCH transmission occasions in a duration

Conclusion

No further discussion in RAN1 for Rel-18 XR to extend the support of legacy single DCI scheduling multi-PDSCHs for FR2-2, to other SCS in FR1/FR2-1.

Decision: As per email decision posted on Oct 19th,

Conclusion

The capacity gain performance results in R1-2208661, R1-2209658 and R1-2209198 corresponding to enhancements based on multi-PDSCH scheduling by a single DCI are captured in XR SI TR.

Conclusion

Study on enhancement for CBG based HARQ-ACK feedback reporting is down-prioritized in RAN1 XR SI.

Conclusion

The following proposed enhancements techniques to improve XR capacity performance are down-prioritized in RAN1 XR SI:

· (P3-5-3) Study on PHR enhancement based on XR traffic arrival periodicity or UL pose periodicity.

· (P3-5-4) Study mechanism of packet dropping based on the PDB requirement, to avoid resource waste due to the out-of-date packets.

Agreement

· For further study the mechanisms to enable HARQ retransmission of a TB on a different cell than the cell of the initial TB transmission for CA operation on TDD cells, consider at least the following:

o Capacity performance evaluation results

o Complexity analysis and RAN2 impact

Conclusion

· Study of soft HARQ-ACK and Delta MCS in RAN1 XR SI for improving XR capacity is down-prioritized.

· Note: The corresponding capacity gain performance results in R1-2210003, R1-2208377 and R1-2203607 are captured in XR SI TR.

Conclusion

· Study on enhanced CQI based on CBG transmission, and study on enhanced CQI based on DMRS for improving XR capacity are down-prioritized in RAN1 XR SI.

· Note: The corresponding capacity gain performance results in R1-2208402 and R1-2209536 are captured in XR SI TR.

R1-2210412 Moderator Summary#3 - Study on XR Specific Capacity Improvements Moderator (Ericsson)

From Oct 19th GTW session

Conclusion

Study on Cooperative MIMO via DL interference probing based on SRS enhancement for improving XR capacity is down prioritized in RAN1 XR SI.

Note: The corresponding capacity gain performance results in R1-2208377 are captured in XR SI TR.

Decision: As per email decision posted on Oct 20th,

Conclusion

No consensus to continue study on differentiation of XR multiple flows based on CG enhancement in RAN1 XR SI.

Conclusion

No consensus to continue study of multi-bits SR mechanisms for capacity improvement of XR traffic in RAN1 XR SI.

Final summary in R1-2210413.

RAN1#111

9.10 Study on XR enhancements for NR

Please refer to RP-220285 for detailed scope of the SI.

[111-R18-XR] – Huilin (Qualcomm)

To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

R1-2212408 Work Plan for Rel-18 SI on XR Enhancements for NR Rapporteur (Nokia, Qualcomm)

From AI 5

R1-2210826 LS on XR and Media Services SA2, vivo

R1-2212855 Draft reply LS on XR and Media Services vivo

R1-2212967 Draft reply LS on XR and Media Services vivo

Decision: The draft LS is endorsed. Final LS is approved in R1-2212994.

From Nov 18th session

Conclusion

From RAN1 perspective, the Rel-18 XR study item in RAN1 is completed.

Email discussion on the approval of XR TR from Nov 28 until Nov 29. Including approval of LS to RAN2.

· R1-2212860, R1-2212936

· Margarita/Huilin (Nokia/Qualcomm)

9.10.1 XR specific power saving techniques

R1-2210906 Discussion on XR-specific power saving techniques Huawei, HiSilicon

R1-2210922 Discussion on power saving enhancements for XR Ericsson

R1-2212518 Discussion on XR specific power saving enhancements vivo (rev of R1-2211024)

R1-2211174 UE Power saving techniques for XR CATT

R1-2211246 Discussion on XR specific power saving techniques Spreadtrum Communications

R1-2211341 Discussions on techniques for XR Power Saving xiaomi

R1-2211389 Discussion on XR specific power saving techniques Intel Corporation

R1-2211490 Discussion on XR specific power saving techniques OPPO

R1-2211536 Discussion on XR specific power saving enhancement for NR China Telecom

R1-2211539 XR specific power saving techniques TCL Communication Ltd.

R1-2211551 XR-specific power saving enhancements Nokia, Nokia Shanghai Bell

R1-2211566 Discussion on XR-specific power saving techniques ETRI

R1-2211624 Discussion on XR-specific power saving techniques Sony

R1-2211653 Discussion on XR specific power saving techniques Panasonic

R1-2211697 Discussion on XR-specific power saving techniques CMCC

R1-2211752 Discussion on XR specific power saving techniques NEC

R1-2211781 XR-specific power saving techniques Lenovo

R1-2211826 On XR specific power saving techniques Apple

R1-2211842 Discussion on XR specific power saving techniques InterDigital, Inc.

R1-2212596 Evaluation on XR specific power saving techniques ZTE, Sanechips (rev of R1-2211905)

R1-2211920 Further Discussion on XR power saving III

R1-2212000 Discussion on XR specific power saving techniques NTT DOCOMO, INC.

R1-2212062 Considerations on Power Savings for XR Samsung

R1-2212134 Power saving techniques for XR Qualcomm Incorporated

R1-2212253 On XR specific power saving techniques MediaTek Inc.

R1-2212305 Discussion on XR-specific power saving techniques LG Electronics

R1-2212387 On XR-specific power saving techniques Google Inc.

R1-2212698 Moderator Summary#1 on XR specific power saving techniques Moderator (Qualcomm Incorporated)

From Nov 15th session

Conclusion

· No consensus to support PDCCH monitoring resume if UE transmits NACK after PDCCH skipping starts

o Nokia, CATT, ZTE, Intel expressed concerns on the benefit of the above proposal

· No consensus to support PDCCH skipping duration enhancements by i) additional PDCCH skipping durations (>3), ii) skipping till the start of next potential data arrival

o Applies at least for the case where CDRX is not configured

§ Ericsson, Nokia, ZTE expressed concerns on the benefit of the above proposal

· No consensus to support additional active time by 1) UE extending DRX active time if UE does not receive XR data within current active time, 2) gNB using dynamic signaling such as a DCI to trigger additional On Duration if the data packet arrives after the On Duration expires

· No consensus to support dynamic periodicity alignment between CDRX and XR traffic

R1-2212699 Moderator Summary#2 on XR specific power saving techniques Moderator (Qualcomm Incorporated)

From Nov 17th session

Conclusion

There is no consensus on the following proposals in Table 1 for CDRX enhancements and Table 2 for PDCCH monitoring enhancements.

Table 1: CDRX enhancements

Proposal for CDRX enhancements

Proposal 2.2: support dynamic periodicity alignment between CDRX and XR traffic

Proposal 2.3-1: support additional active time by UE extending DRX active time if UE does not receive XR data within current active time

Proposal 2.3-2: support additional active time by gNB using dynamic signaling such as a DCI to trigger additional On Duration if the data packet arrives after the On Duration expires

Proposal 2.4: support non-uniform PMOs within CDRX On Duration

Proposal 2.5: support two-stage CDRX On Duration

Proposal 2.6-1: support early stopping of On-Duration timer by inactivity timer expiration

Proposal 2.6-2: support early stopping of On-Duration timer after a time window after the reception of XR data

Proposal 2.7: support multiple active CDRX configurations

Proposal 2.8: support dynamic grant enhancement with XR-specific pre-scheduling

Proposal 2.9: support SPS+DG with UE power saving scheme

Proposal 2.10: Support XR-specific plyaoutDelayForMediaStartup for XR UE power saving enhancement

Table 2: PDCCH monitoring adaptation enhancements

Proposals for PDCCH monitoring adaptation enhancements

Proposal 3.1: support PDCCH monitoring resume if UE transmits NACK after PDCCH skipping starts

Proposal 3.2-1: support PDCCH skipping duration enhancements by additional PDCCH skipping durations (>3)

Proposal 3.2-2: support PDCCH skipping duration enhancements by PDCCH skipping till the start of next potential data arrival

Proposal 3.3-1: support non-scheduling DCI based PDCCH skipping indication

Proposal 3.3-2: support continuous PDCCH skipping, i.e., UE continuously skips the PDCCH MOs until the DCI is successfully decoded at the time of packet arrival

Proposal 3.4: support an implicit SSSG at the start of drx-OnDuration and another SSSG applies when a PDCCH for data traffic is received, with search space set monitoring pattern aligned with DRX cycle

R1-2212700 Moderator Summary#3 on XR specific power saving techniques Moderator (Qualcomm Incorporated)

Presented in Nov 18th session.

Final summary in R1-2212701.

9.10.22 XR-specific capacity enhancements techniques

R1-2210849 XR Capacity Evaluation and Enhancements FUTUREWEI

R1-2212650 Discussion on XR-specific capacity enhancements techniques Huawei, HiSilicon (rev of R1-2210907)

R1-2210923 Discussion on capacity enhancements for XR Ericsson

R1-2212595 Discussion on XR specific capacity enhancements vivo (rev of R1-2211025)

R1-2211175 NR enhancement for XR capacity improvement CATT

R1-2211415 Discussion on XR specific capacity enhancement techniques Intel Corporation

R1-2211491 Discussion on XR specific capacity enhancements techniques OPPO

R1-2211540 XR-specific capacity enhancements techniques TCL Communication Ltd.

R1-2211552 XR-specific capacity enhancements Nokia, Nokia Shanghai Bell

R1-2211625 XR-specific capacity enhancements and evaluation results Sony

R1-2211654 Discussion on XR capacity enhancement techniques Panasonic

R1-2211698 Discussion on XR-specific capacity enhancements techniques CMCC

R1-2211782 XR-specific Capacity Enhancement Techniques Lenovo

R1-2211827 On XR-specific capacity enhancements techniques Apple

R1-2211843 Discussion on XR-specific capacity enhancements techniques InterDigital, Inc.

R1-2211906 XR specific capacity enhancements ZTE, Sanechips

R1-2212001 Discussion on XR specific capacity improvement enhancements NTT DOCOMO, INC.

R1-2212063 Considerations on Capacity Improvements for XR Samsung

R1-2212135 Capacity enhancement techniques for XR Qualcomm Incorporated

R1-2212254 On XR specific capacity improvement enhancement MediaTek Inc.

R1-2212275 Discussion on XR-specific capacity enhancements techniques KT Corp.

R1-2212306 Discussion on XR-specific capacity enhancement techniques LG Electronics

R1-2212365 Discussion on XR-specific capacity enhancements NEC

R1-2212386 On XR-specific capacity enhancements techniques Google Inc.

R1-2212606 Moderator Summary#1 - Study on XR Specific Capacity Improvements Moderator (Ericsson)

From Nov 15th session

R1-2212732 [Draft] TR 38.835 - TP for Capacity evaluation results Rapporteur (Nokia) (rev of R1-2212407)

Decision: The TPs for XR TR in R1-2212732 are endorsed in principle.

Conclusion

· The capacity gain performance results in R1-2210907 (Huawei/HiSilicon) corresponding to enhancements based on UL delay aware scheduling are captured in XR SI TR.

Conclusion

· The capacity gain performance results in R1-2211906 (ZTE/Sanechips) and R1-2211175 (CATT) corresponding to BSR enhancements are captured in XR SI TR.

Conclusion

· The capacity gain performance results in R1-2211175 (CATT) corresponding to enhanced CG+DG scheme are captured in XR SI TR.

o Note: SU-MIMO is used for baseline and MU-MIMO for the proposed enhancement.

Conclusion

· The capacity gain performance results in R1-2211175 (CATT) corresponding to XR-specific playoutDelayForMediaStartup enhancement scheme are captured in XR SI TR.

Agreement:

Support dynamic indication of the unused CG PUSCH occasion(s) based on UCI (e.g., CG-UCI or a new UCI) by the UE.

Agreement:

Support multiple CG PUSCH transmission occasions in a period of a single CG PUSCH configuration.

Conclusion

No consensus on the following

· Support dynamic indication of the unused CG PUSCH resource(s) based on UCI (e.g., CG-UCI or a new UCI) by the UE

R1-2212607 Moderator Summary#2 - Study on XR Specific Capacity Improvements Moderator (Ericsson)

From Nov 17th session

Conclusion:

· Deprioritize discussion on HARQ retransmission of a TB on a different cell than the cell of the initial TB transmission for CA operation on TDD cells in XR agenda.

Conclusion:

· Deprioritize in RAN1, the study of XR-specific playoutDelayForMediaStartup for XR awareness scheduling to improve XR capacity enhancement.

Conclusion:

The capacity gain performance results in R1-2210907 and R1-2212254 corresponding to enhancements on RRM measurement are captured in XR SI TR.

Conclusion

No consensus on the following:

Enhancements on RRM to relax scheduling restriction for at least for intra-frequency RRM without MGs in FR2 and for inter-frequency RRM with MGs.

R1-2212608 Moderator Summary#3 - Study on XR Specific Capacity Improvements Moderator (Ericsson)

From Nov 18th session

Agreement

The following TP for section 5.3.1 is endorsed in principle for TR 38.835:

The following enhancements for configured grant based transmission are recommended:

· Multiple CG PUSCH transmission occasions in a period of a single CG PUSCH configuration;

· Dynamic indication of unused CG PUSCH occasion(s) based on UCI (e.g., CG-UCI or a new UCI) by the UE.

The corresponding capacity performance evaluation results are available in Annex B.1.6.

The evaluation results for other proposed and studied capacity enhancement schemes are available in Annex B.1.

Final summary in R1-2212609.

RAN1#112

9.10 XR Enhancements for NR

Please refer to RP-223502 for detailed scope of the WI.

[112-R18-XR] – Sorour (Ericsson)

To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

R1-2301626 Work Plan for Rel-18 WI on XR Enhancements for NR Nokia, Qualcomm (Rapporteurs), Ericsson (RAN1 FL)

9.10.11 XR-specific capacity enhancements

R1-2300070 XR-specific capacity enhancements FUTUREWEI

R1-2300123 Discussion on CG enhancements for XR capacity Huawei, HiSilicon

R1-2300137 Capacity Enhancements for XR Ericsson

R1-2300235 Discussion on XR-specific capacity enhancements Spreadtrum Communications

R1-2300291 Discussion on XR specific capacity enhancements OPPO

R1-2300326 On XR-specific capacity enhancements techniques Google Inc.

R1-2300374 Discussion on XR specific capacity enhancements ZTE, Sanechips

R1-2300471 Discussion on XR specific capacity enhancements vivo

R1-2300493 Discussion on XR-specific capacity enhancements FGI

R1-2300552 Discussion on XR-specific capacity enhancements xiaomi

R1-2300657 Design of Multiple CG Occasions CATT

R1-2300739 XR-specific capacity enhancements Nokia, Nokia Shanghai Bell

R1-2300783 Discussion on XR-specific capacity enhancements InterDigital Communications

R1-2300818 Discussion on XR-specific capacity enhancements NEC

R1-2300839 XR-specific capacity enhancements techniques TCL Communication Ltd.

R1-2300887 Considerations on XR-specific capacity enhancements Sony

R1-2300965 Discussion on XR capacity enhancement techniques Intel Corporation

R1-2301020 Discussion on XR-specific capacity enhancements CMCC

R1-2301034 Discussion on XR-specific capacity enhancements DENSO CORPORATION

R1-2301100 Discussion on XR capacity enhancement techniques Panasonic

R1-2301111 Discussion on XR-specific capacity enhancements LG Electronics

R1-2301207 XR-related CG Enhancements Lenovo

R1-2301282 Capacity Improvements for XR Samsung

R1-2301364 Discussion on XR-specific capacity enhancements Apple

R1-2301431 Capacity Enhancement Techniques for XR Qualcomm Incorporated

R1-2301511 Discussion on XR-specific capacity enhancements NTT DOCOMO, INC.

R1-2301780 Discussion on XR capacity enhancements MediaTek Inc. (rev of R1-2301606)

R1-2301900 Moderator Summary#1 - XR Specific Capacity Improvements Moderator (Ericsson)

From Tuesday session

Conclusion

For convenience in discussion, the term "multi-PUSCHs CG" refers to " a CG PUSCH configuration with multiple CG PUSCH transmission occasions within a period of the CG PUSCH configuration".

Agreement

· Multi-PUSCHs CG is supported for Type-1 configured grant.

· Multi-PUSCHs CG is supported for Type-2 configured grant.

Agreement

For determination of the time domain resource allocation of CG PUSCHs associated to a multi-PUSCHs CG, the following alternatives for further study:

Alt-A: TDRA determination based on repetition framework.

Alt-A1: Follow the time domain resource mapping of Type A repetition

N configured by higher layers or indicated by activation DCI
Single SLIV is determined from TDRA
The same SLIV in N PUSCH in consecutive slots per CG period

FFS for non-consecutive slots

FFS details, including related RRC parameters

Alt-A2: Follow the time domain resource mapping of Type B repetition

N configured by higher layers or indicated by activation DCI
Single SLIV is determined from TDRA

The SLIV used for 1^st PUSCH per CG period.

N consecutive nominal PUSCHs with same duration per CG period
Note: N is not necessarily the repetition factor.

FFS details, including related RRC parameters

Alt-B: TDRA determination based on NR-U framework

N and M configured by higher layers
Single SLIV is determined from TDRA.

The SLIV used for 1^st PUSCH per CG period.

M consecutive PUSCH TOs with same duration in slot. The M PUSCH TOs are used in N consecutive slots per CG period
Note: N and M are configured independently from cg-nrofSlots-r16 and cg-nrofPUSCH-InSlot-r16, respectively. M and N configuration is independent from cgRetransmissionTimer configuration.
FFS details, including related RRC parameters

Alt-C: TDRA determination based on single DCI scheduling multiple PUSCHs

Alt-C1: Follow Rel-16 single DCI scheduling multiple PUSCHs

TDRA configured by pusch-TimeDomainAllocationListForMultiPUSCH-r16 with k2-r16
A row of TDRA with N entries determines the time domain resources allocation of N PUSCH TOs per period

Note: N PUSCH TOs should be consecutive PUSCH TOs in consecutive slots.

FFS details, including related RRC parameters

Alt-C2: Follow Rel-17 single DCI scheduling multiple PUSCHs

TDRA configured by pusch-TimeDomainAllocationListForMultiPUSCH-r16 with extendedK2-r17
A row of TDRA with N entries determines the time domain resources allocation of N PUSCH TOs per period

Note: N PUSCH TOs can be non-consecutive PUSCHs and/or in non-consecutive slots.

FFS details, including related RRC parameters

Agreement

For the PUSCHs parameters in a multi-PUSCHs CG configuration, the configuration/indication parameters except MCS and FDRA of CG PUSCHs in a multi-PUSCHs CG configuration are the same

· FFS: For MCS and FDRA, study further to decide whether/how to be different.

· FFS: Applicability to type-1 and type-2

· Note: TDRA and HP ID are not in this scope of the above statement.

Conclusion

RAN1 discusses to decide how to determine the HARQ process ID of CG PUSCHs of a multi-PUSCHs CG.

Agreement

For determination of HARQ process IDs associated to PUSCHs in multi-PUSCHs CG assuming one TB per PUSCH, consider the following alternatives:

Alt. 1: The HARQ process ID for the first configured/valid PUSCH in a period is determined based on the legacy CG procedure when cg-RetransmissionTimer is not configured, and applying "the period duration divided by X instead of the period duration.

The HARQ process ID of the remaining PUSCHs in the period is determined by incrementing the HARQ process ID of the preceding PUSCH in the period.
Alt 1-1; X = 1
Alt 1-2: X is the number of configured PUSCHs in a period
Alt 1-3: X is provided by RRC configuration.
FFS details

Alt. 2: Support that UE can decide, as in NR-U, the HARQ IDs for the multiple CG PUSCH transmission occasions and indicate the decided HARQ IDs to gNB if multiple HARQ processes are used for the multiple CG PUSCH transmission occasions in a period of a single CG PUSCH configuration

FFS details

Alt. 3: The HARQ process ID for the configured PUSCHs in a period is determined based on the legacy CG procedure when cg-RetransmissionTimer is not configured.

FFS on potential enhancements different from previous alternatives
Alt 3-1: Note: Same HP ID would be used for all PUSCHs within a period.

FFS details

Alt 3-2: Note: Different HP ID could be used for all PUSCHs within a period.

FFS details

Alt. 4: The HARQ process ID for the first configured/valid PUSCH in a period is determined based on the legacy CG procedure when cg-RetransmissionTimer is not configured.

The HARQ process ID of the remaining PUSCHs in the period is determined by incrementing the HARQ process ID of the preceding PUSCH in the period
FFS on potential enhancements different from previous alternatives

Alt 5: Support that UE can decide, as in NR-U, the HARQ IDs for the first CG PUSCH transmission occasions and indicate the decided HARQ IDs to gNB if multiple HARQ processes are used for the multiple CG PUSCH transmission occasions in a period of a single CG PUSCH configuration

The HARQ process ID of the remaining PUSCHs in the period is determined by incrementing the HARQ process ID of the preceding PUSCH in the period
FFS details

Alt 6: FFS other solutions

Note: The case of one TB map to multiple PUSCHs is not considered here.

R1-2301901 Moderator Summary#2 - XR Specific Capacity Improvements Moderator (Ericsson)

From Thursday session

Agreement

The physical channel that carries the UCI that provides information about unused CG PUSCH transmission occasions is CG PUSCH.

Agreement

Encoding and multiplexing for “the UCI that provides information about unused CG PUSCH transmission occasions” in a CG PUSCH applies encoding and multiplexing procedures for CG-UCI as baseline.

· FFS on details

Agreement

Consider the following alternatives for “the UCI that provides information about unused CG PUSCH transmission occasions” for down-selection or revision

· Alt. 1: “The UCI that provides information about unused CG PUSCH transmission occasions” is defined as a new UCI.

o FFS on details

· Alt. 2: “The UCI that provides information about unused CG PUSCH transmission occasions” is added as new field(s) to the CG-UCI.

o FFS on details

· Alt. 3: “The UCI that provides information about unused CG PUSCH transmission occasions” replaces/re-purposes some field(s) of the CG-UCI.

o FFS on details

R1-2301902 Moderator Summary#3 - XR Specific Capacity Improvements Moderator (Ericsson)

From Friday session

Agreement

For dynamic indication of unused CG PUSCH occasion(s) based on a UCI, the following options for further down-scoping with possible revision, are considered for the transmission occasion of the UCI:

Option 1: A transmitted CG PUSCH, includes the UCI.

FFS details

Option 2: A transmitted CG PUSCH includes the UCI, if it is transmitted in an occasion determined by RRC.

FFS details

Option 3: A transmitted CG PUSCH includes the UCI, if it is transmitted in a pre-defined transmission occasion.

FFS details

Example of a pre-determined occasion: 1^st configured PUSCH TO in a CG period or 1^st configured PUSCH TO in a multiple CG periods

Option 4: A transmitted CG PUSCH includes the UCI, if it is transmitted in a transmission occasion determined satisfying given condition(s).

FFS details

Examples of a condition: A first transmitted PUSCH in a CG period, or a first PUSCH transmission within a multiple of CG periods.

Other options are not precluded. Proponent companies to provide details.

Agreement

For dynamic indication of unused CG PUSCH transmission occasion(s) based on a UCI, the following options for further down-scoping, are considered for the information provided by the UCI:

Option 1: The UCI determines the consecutive CG PUSCH TO(s) that are indicated as “unused”

Option 1-1: The UCI provides the number of consecutive TO(s) in time domain.

Applicable numbers can be determined from information obtained from configuration.
FFS details

Option 1-2: The UCI provides a time duration/range that includes the consecutive TO(s) in time domain.

Applicable time duration/range can be determined from information obtained from configuration
FFS details

Option 2: The UCI determines the CG PUSCH TO(s) that are indicated as “unused” (consecutive/non-consecutive TO(s) in time domain)

Option 2-1: The UCI provides a bitmap where a bit corresponds to a TO within a time duration/range. The bit indicates whether the TO is “unused”.

Applicable time duration/range can be determined from information obtained from configuration
FFS details

Option 2-2: The UCI provides a bitmap where a bit corresponds to TOs within a time duration/range. The bit indicates whether all TOs within the time duration/range are “unused”.

Applicable time duration/range can be determined from information obtained from configuration
FFS details

FFS whether/how the unused TO(s) can be associated to multiple CG configuration.
Other options are not precluded. Proponent companies to provide details.

Final summary in R1-2301903.

RAN1#112-bis-e

9.8 XR Enhancements for NR

Please refer to RP-230786 for detailed scope of the WI.

Including discussions on PDCCH monitoring resumption after UL NACK. Interested companies are to submit draft CR(s) to show the impacts of adding this functionality. These tdocs are to be submitted to agenda item 9.8.

R1-2303826 Work Plan for Rel-18 WI on XR Enhancements for NR Nokia, Qualcomm (Rapporteurs), Ericsson (RAN1 FL)

R1-2302398 PDCCH monitoring resumption after UL NACK Ericsson

R1-2302500 Draft CR on PDCCH monitoring resumption after NACK vivo, MediaTek, Google, Qualcomm, Panasonic, Meta, Ericsson, China Unicom, Huawei, HiSilicon, Xiaomi, Apple, China Telecom

R1-2302676 PDCCH Skipping interaction with HARQ CATT

R1-2302946 Discussion on PDCCH monitoring resumption after reporting NACK ZTE, Sanechips

R1-2303312 Draft CR for Introducing PDCCH monitoring resumption after UL NACK Nokia, Nokia Shanghai Bell

[112bis-e-R18-XR-01] – Sorour (Ericsson)

Email discussion on PDCCH monitoring resumption after UL NACK by April 21st

R1-2304041 Moderator Summary#1 - PDCCH monitoring resume after UL NACK Moderator (Ericsson)

From April 18th GTW session

Proposal 1:

The following is supported: Resume PDCCH monitoring if UE transmits NACK after PDCCH skipping is started.

Support: vivo, MediaTek, Google, Qualcomm, Panasonic, Meta, Ericsson, China Unicom, Huawei/HiSilicon, Xiaomi, Apple, China Telecom, ZTE/Sanechips, Nokia/NSB, Futurewei, Samsung, TCL
Not Support: CATT, Intel, OPPO, Spreadtrum, LG

R1-2304042 Moderator Summary#2 - PDCCH monitoring resume after UL NACK Moderator (Ericsson)

From April 24th GTW session

Outcome of discussion on PDCCH monitoring resume after UL NACK

In RAN1#112bis-e, text proposal alternatives to implement PDCCH monitoring resumption after UL NACK after PDCCH skipping is started were provided in R1-2304042 (by the moderator based on email discussions). The text proposal alternatives were to be discussed and finalized so that RAN1 can submit a converged text proposal to RAN. However, during the review process, CATT and Intel expressed sustained objections on the candidate TPs. They also expressed sustained objections on the support of this feature.

Final summary in R1-2304043.

9.8.11 XR-specific capacity enhancements

R1-2302317 XR-specific capacity enhancements FUTUREWEI

R1-2302346 Discussion on CG enhancements for XR capacity Huawei, HiSilicon

R1-2302399 Capacity Enhancements for XR Ericsson

R1-2302429 Discussions on XR-specific capacity enhancements New H3C Technologies Co., Ltd.

R1-2302501 Discussion on XR specific capacity enhancements vivo

R1-2302563 Discussion on XR specific capacity enhancements OPPO

R1-2302615 Discussion on XR-specific capacity enhancements Spreadtrum Communications

R1-2302718 Design of Multiple CG Occasions CATT

R1-2302811 Discussion on XR specific capacity enhancement techniques Intel Corporation

R1-2302836 XR-specific capacity enhancements techniques TCL Communication Ltd.

R1-2302856 Discussion on XR-specific capacity enhancements Sony

R1-2302879 On XR-specific capacity enhancements techniques Google Inc.

R1-2302893 Discussion on XR capacity enhancement techniques Panasonic

R1-2302947 Discussion on XR specific capacity enhancements ZTE, Sanechips

R1-2302997 Discussion on XR-specific capacity enhancements xiaomi

R1-2303023 Discussion on XR-specific capacity enhancements InterDigital, Inc.

R1-2303143 Capacity improvements for XR Samsung

R1-2303190 Discussion on XR specific capacity enhancements CAICT

R1-2303249 Discussion on XR-specific capacity enhancements CMCC

R1-2303311 XR-specific capacity enhancements Nokia, Nokia Shanghai Bell

R1-2303356 On XR capacity enhancements MediaTek Inc.

R1-2303409 Discussion on XR-specific capacity enhancements FGI

R1-2303428 Discussion on XR-specific capacity enhancements LG Electronics

R1-2303460 Remaining issues on XR-specific capacity enhancements Sharp

R1-2303498 XR-specific capacity enhancements Apple

R1-2303533 XR-related CG Enhancements Lenovo

R1-2303605 Capacity Enhancement Techniques for XR Qualcomm Incorporated

R1-2303672 Discussion on XR-specific capacity enhancements NEC

R1-2303724 Discussion on XR-specific capacity enhancements NTT DOCOMO, INC.

R1-2303827 Discussion on XR-specific capacity enhancements DENSO CORPORATION

[112bis-e-R18-XR-02] – Sorour (Ericsson)

Email discussion on XR-specific capacity enhancements by April 26th

- Check points: April 21, April 26

R1-2304044 Moderator Summary#1 - XR Specific Capacity Improvements Moderator (Ericsson)

From April 18th GTW session

Agreement

For TDRA design for multi-CG PUSCH, prioritize Alt-A1, Alt-B, and Alt-C2 for further downscoping and/or modification from corresponding agreement in RAN1#112.

· FFS: How to address TDD configuration issue

Agreement

For CG PUSCHs in a multi-PUSCHs CG configuration, MCS of the CG PUSCHs in the CG configuration are the same between different PUSCH occasions.

Agreement

For CG PUSCHs in a multi-PUSCHs CG configuration, FDRA of the CG PUSCHs in the CG configuration are the same between different PUSCH occasions.

R1-2304045 Moderator Summary#2 - XR Specific Capacity Improvements Moderator (Ericsson)

From April 20th GTW session

Agreement

For dynamic indication of unused CG PUSCH transmission occasion(s) based on a UCI, the indicated “unused” CG PUSCH TO(s), if any, by the UCI in a CG PUSCH for a CG configuration

can be consecutive or non-consecutive CG PUSCH TO(s) in time domain [in one CG period]
FFS whether/how the unused TO(s) can be associated to multiple CG configuration.

Note: FFSs and further details in corresponding agreement in RAN1#112 for the selected option are remained for further discussion

Note: Above corresponds to Option 2 (w.r.t. agreement in RAN1#112)

Agreement

Option 1: For a CG PUSCH configuration, the UTO-UCI is included in every CG PUSCH that is transmitted (that is Option 1 in corresponding agreement in RAN1#112)

FFS details

Note: The term “UTO-UCI” refers to the “UCI that provides information about unused CG PUSCH transmission occasions” for convenience.

Agreement

The UCI that provides information about unused CG PUSCH transmission occasions is defined as a “new UCI” (i.e. Alt. 1 of previous agreement).

Agreement

With respect to PHY two-level priority, for a configured grant PUSCH configuration, the “UTO-UCI” has the same priority level as the configured grant PUSCH.
Note: The term “UTO-UCI” refers to the “UCI that provides information about unused CG PUSCH transmission occasions” for convenience.

R1-2304046 Moderator Summary#3 - XR Specific Capacity Improvements Moderator (Ericsson)

From April 24th GTW session

Agreement

The existing CG-UCI encoding and multiplexing procedures are reused for encoding the “UTO-UCI” in a configured grant PUSCH in absence or presence of other UCIs being multiplexed in the PUSCH, by applying the following adjustments:

The “UTO-UCI” is used instead of CG-UCI in the corresponding procedures for encoding of CG-UCI and/or HARQ-ACK, whichever is present.
For determining the beta-offset,

Beta offset is configured for the “UTO-UCI”

If UTO-UCI and HARQ-ACK is not jointly encoded, the beta offset for the “UTO-UCI” is used in the procedures instead of CG-UCI beta offset
If UTO-UCI and HARQ-ACK is jointly encoded, HARQ-ACK beta offset is used in the procedures instead of CG-UCI beta offset

FFS on sequence generation order between UTO-UCI and HARQ-ACK
FFS on dropping rule between UTO-UCI and HARQ-ACK when joint encoding is not configured
Note: The term “UTO-UCI” refers to the “UCI that provides information about unused CG PUSCH transmission occasions” for convenience.

R1-2304047 Moderator Summary#4 - XR Specific Capacity Improvements Moderator (Ericsson)

From April 26th GTW session

Agreement

From RAN1 perspective, for determination of HARQ process Ids associated to PUSCHs in multi-PUSCHs CG assuming one TB per PUSCH:

The HARQ process ID for the first configured/valid PUSCH in a period is determined based on the legacy CG procedure when cg-RetransmissionTimer is not configured, and applying the following formula, whichever is applicable

HARQ Process ID = [floor(X*(CURRENT_symbol – offset1) / periodicity) + offset2] modulo nrofHARQ-Processes
HARQ Process ID = [floor(X*(CURRENT_symbol – offset1) / periodicity) + offset2] modulo nrofHARQ-Processes + harq-ProcID-Offset2

FFS whether in formulas above X is outside or inside floor operation, i.e.

HARQ Process ID = [X*floor( (CURRENT_symbol – offset1) / periodicity) + offset2] modulo nrofHARQ-Processes
HARQ Process ID = [X*floor((CURRENT_symbol – offset1) / periodicity) + offset2] modulo nrofHARQ-Processes + harq-ProcID-Offset2

(Working Assumption) The HARQ process ID of the remaining configured/valid CG PUSCHs in the period is determined by incrementing the HARQ process ID of the preceding PUSCH in the period by Y with module operation with nrofHARQ-Processes or module operation with (nrofHARQ-Processes + harq-ProcID-Offset2), whichever applicable.

FFS whether X=1 or X= the number of configured PUSCHs in the CG period
FFS whether Y =1 or a value larger than 1, e.g. Y=2.

FFS: If Y>1, Y is determined based on RRC

FFS whether Offset 1= 0 or can be a non-zero value.

FFS: If offset1 is non-zero, how offset1 is determined (i.e., based on RRC)

FFS whether Offset 2= 0 or can be a non-zero value.

FFS: If offset2 is non-zero, how offset2 is determined (i.e., based on RRC or dynamically)

Note1: The equations will be updated accordingly when FFSs are clarified, e.g., if X=1, remove X; if Y=1, remove Y; if non-zero offset1 or Offset 2 is not supported, remove offset 1 or Offset 2.
Note2: A configured CG PUSCH is invalid if the CG PUSCH is dropped due to collision with DL symbol(s) indicated by tdd-UL-DL-ConfigurationCommon or tdd-UL-DL-ConfigurationDedicated or SSB.

Agreement

The UTO-UCI provides a bitmap where a bit corresponds to a TO within a time duration/range. The bit indicates whether the TO is “unused”.

· FFS: Details including time duration/range

Note: The term “UTO-UCI” refers to the “UCI that provides information about unused CG PUSCH transmission occasions” for convenience.

Final summary in R1-2304048.

RAN1#113

9.8 XR Enhancements for NR

Please refer to RP-230786 for detailed scope of the WI.

Including discussions on PDCCH monitoring resumption after UL NACK.

[113-R18-XR] – Sorour (Ericsson)

Email discussion on XR

- To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

R1-2305865 Work Plan for Rel-18 WI on XR Enhancements for NR Nokia, Qualcomm (Rapporteurs), Ericsson (RAN1 FL)

R1-2305257 Discussion on PDCCH monitoring resumption after UL NACK Apple

R1-2304494 Draft CR on PDCCH monitoring resumption after NACK vivo, MediaTek, Ericsson, Xiaomi, ZTE, Sanechips, China Telecom, China Unicom, Qualcomm, LGE, Huawei, HiSilicon, Google, Meta, Apple

R1-2305864 Draft CR for Introducing PDCCH monitoring resumption after UL NACK Nokia, Nokia Shanghai Bell

From Friday session

RAN1 reviewed two TPs but was not able to converge.

9.8.11 XR-specific capacity enhancements

R1-2304354 XR-specific capacity enhancements FUTUREWEI

R1-2304384 Discussions on XR-specific capacity enhancements New H3C Technologies Co., Ltd.

R1-2304413 Capacity Enhancements for XR Ericsson

R1-2304495 Discussion on XR specific capacity enhancements vivo

R1-2304529 Discussion on XR specific capacity enhancements ZTE, Sanechips

R1-2304572 Discussion on XR-specific capacity enhancements Spreadtrum Communications

R1-2304617 Discussion on XR capacity enhancement techniques Panasonic

R1-2304665 Discussion on CG enhancements for XR capacity Huawei, HiSilicon

R1-2304745 Design of Multiple CG Occasions and unused CG occasion feedback CATT

R1-2304915 Discussion on XR-specific capacity enhancements xiaomi

R1-2304980 Discussion on XR-specific capacity enhancements Honor

R1-2304981 Discussion on XR-specific capacity enhancements DENSO CORPORATION

R1-2304993 Discussion on XR-specific capacity enhancements NEC

R1-2305022 Discussion on XR specific capacity enhancements CAICT

R1-2305047 On XR-specific capacity enhancements techniques Sony

R1-2305074 On XR-specific capacity enhancements techniques Google Inc.

R1-2305108 Discussion on XR-specific capacity enhancements CMCC

R1-2305135 XR-specific capacity enhancements techniques TCL Communication Ltd.

R1-2305145 Discussion on XR-specific capacity enhancements LG Electronics

R1-2305175 Discussion on XR-specific capacity enhancements InterDigital, Inc.

R1-2305196 Remaining issues on XR-specific capacity enhancements Sharp

R1-2305211 XR-related CG Enhancements Lenovo

R1-2305258 XR-specific capacity enhancements Apple

R1-2305351 Capacity Enhancement Techniques for XR Qualcomm Incorporated

R1-2305468 Discussion on XR specific capacity enhancements OPPO

R1-2305528 Capacity enhancements for XR Samsung

R1-2305554 On XR-specific capacity enhancements KT Corp.

R1-2305610 Discussion on XR-specific capacity enhancements NTT DOCOMO, INC.

R1-2305663 On XR capacity enhancements MediaTek Inc.

R1-2305781 Discussion on XR-specific capacity enhancements FGI

R1-2305863 XR-specific capacity enhancements Nokia, Nokia Shanghai Bell

R1-2306086 Moderator Summary#1 - XR Specific Enhancements Moderator (Ericsson)

From Tuesday session

Working Assumption (see further update from Thursday session)

For time domain resource allocation for multi-PUSCH CGs, support

For TDRA determination (based on NR-U framework)

For Type-1, follow the rules for DCI format 0_0 on UE specific search space, as defined in Clause 6.1.2.1.1 of TS 38.214.

Note: To determine the configuration of TDRA, PUSCH repetition type A is assumed according to description in 6.1.2.3 in 38.214 for Type-1.

It is still an open issue whether repetition is supported. If it is decided repetition is not supported, it implies the corresponding repetition factor for is one.

For Type-2, the TDRA table is determined by the TDRA table associated with activation DCI, as defined in Clause 6.1.2.1 of TS 38.214.

Note: The DCI format for activation DCI with pusch-RepTypeA is applicable.

It is still an open issue whether repetition is supported. If it is decided repetition is not supported, it implies the corresponding repetition factor for is one.

N is configured by higher layers
A single SLIV is determined from TDRA.

The SLIV used for 1^st PUSCH per CG period.

The PUSCH is used in each of N consecutive slots per CG period
Note: N is configured independently from cg-nrofSlots-r16 and cg-nrofPUSCH-InSlot-r16, respectively. N configuration is independent from cgRetransmissionTimer configuration.
To determine corresponding slots for CG PUSCHs in a period of a multi-PUSCH CG configuration:

For the first PUSCH in the period, follow the legacy procedures.
For remaining PUSCHs in the period

ForType-1 and Type-2, reuse the corresponding procedures for NR-U by applying the RRC parameter N, instead of cg-nrofSlots-r16 and cg-nrofPUSCH-InSlot-r16, respectively.

FFS: Whether/How to further enhance for operation on TDD

Agreement

With respect to the agreement on HARQ process ID determination for multi-PUSCH Cg in RAN1#112bis-e, support the following:

Y=1
Offset 1=0 (i.e., remove Offset 1)
Offset 2=0 (i.e., remove Offset 2)

Agreement

When a CG PUSCH occasion is indicated as “unused”, the UE is not allowed to transmit CG PUSCH on that CG PUSCH occasion.
For any other CG PUSCH occasion that is NOT indicated as “unused”, the UE is allowed to transmit or not to transmit CG PUSCH on that CG PUSCH occasion as per legacy specification.

No RAN1 specification impact

R1-2306087 Moderator Summary#2 - XR Specific Enhancements Moderator (Ericsson)

From Thursday session

Tuesday WA is confirmed as follows:

Agreement

For time domain resource allocation for multi-PUSCH CGs, support

For TDRA determination (based on NR-U framework)

For Type-1, follow the rules for DCI format 0_0 on UE specific search space, as defined in Clause 6.1.2.1.1 of TS 38.214.

Note: To determine the configuration of TDRA, PUSCH repetition type A is assumed according to description in 6.1.2.3 in 38.214 for Type-1.

It is still an open issue whether repetition is supported. If it is decided repetition is not supported, it implies the corresponding repetition factor for is one.

For Type-2, the TDRA table is determined by the TDRA table associated with activation DCI, as defined in Clause 6.1.2.1 of TS 38.214.

Note: The DCI format for activation DCI with pusch-RepTypeA is applicable.

It is still an open issue whether repetition is supported. If it is decided repetition is not supported, it implies the corresponding repetition factor for is one.

N is configured by higher layers
A single SLIV is determined from TDRA.

The SLIV used for 1^st PUSCH per CG period.

The PUSCH is used in each of N consecutive slots per CG period
Note: N is configured independently from cg-nrofSlots-r16 and cg-nrofPUSCH-InSlot-r16, respectively. N configuration is independent from cgRetransmissionTimer configuration.
To determine corresponding slots for CG PUSCHs in a period of a multi-PUSCH CG configuration:

For the first PUSCH in the period, follow the legacy procedures.
For remaining PUSCHs in the period

ForType-1 and Type-2, reuse the corresponding procedures for NR-U by applying the RRC parameters N, instead of cg-nrofSlots-r16 and cg-nrofPUSCH-InSlot-r16, respectively.

Conclusion

For time domain resource allocation for multi-PUSCH CGs, there is no consensus for further enhancement for operation on TDD.

Agreement

For determination of HARQ process IDs associated to PUSCHs in multi-PUSCHs CG assuming one TB per PUSCH:

· X is outside the floor operation

· X= the number of configured PUSCHs in the CG period

Send an LS to RAN2 to inform this agreement.

Agreement

The following working assumption is confirmed

(Working Assumption) The HARQ process ID of the remaining configured/valid CG PUSCHs in the period is determined by incrementing the HARQ process ID of the preceding PUSCH in the period by one with module operation with nrofHARQ-Processes or module operation with (nrofHARQ-Processes + harq-ProcID-Offset2), whichever applicable.

Agreement

A CG PUSCH occasion indicated as “unused” earlier, is not allowed to be indicated as “NOT unused later”.
A CG PUSCH occasion indicated as “NOT unused” earlier, can be indicated as “unused” later.

FFS: Whether there is specification impact

Agreement

The UTO-UCI indication for a CG configuration is applicable to only valid CG PUSCH TOs, if any.

· Note: A configured CG PUSCH is invalid if the CG PUSCH is dropped due to collision with DL symbol(s) indicated by tdd-UL-DL-ConfigurationCommon or tdd-UL-DL-ConfigurationDedicated or SSB. Otherwise, it is valid.

R1-2306088 Moderator Summary#3 - XR Specific Enhancements Moderator (Ericsson)

From Friday session

Agreement

From RAN1 perspective, for determination of HARQ process IDs associated to PUSCHs in multi-PUSCHs CG assuming one TB per PUSCH:

The HARQ process ID for the first configured~~/valid~~ PUSCH in a period is determined based on the legacy CG procedure when cg-RetransmissionTimer is not configured, and applying the following formula, whichever is applicable

HARQ Process ID = [X*floor( (CURRENT_symbol ) / periodicity)] modulo nrofHARQ-Processes
HARQ Process ID = [X*floor((CURRENT_symbol ) / periodicity)] modulo nrofHARQ-Processes + harq-ProcID-Offset2

X= the number of configured PUSCHs in the CG period

The HARQ process ID of the remaining configured/ and valid CG PUSCHs in the period is determined by incrementing the HARQ process ID of the preceding PUSCH in the period by one with module operation with nrofHARQ-Processes or module operation with (nrofHARQ-Processes + harq-ProcID-Offset2), whichever applicable.
Note: A configured CG PUSCH is invalid if the CG PUSCH is dropped due to collision with DL symbol(s) indicated by tdd-UL-DL-ConfigurationCommon or tdd-UL-DL-ConfigurationDedicated or SSB.

Send an LS to RAN2 to convey the above RAN1 agreement. Final LS is in R1-2306233.

R1-2306232 [Draft] LS on XR capacity enhancements Moderator (Ericsson)

Decision: The draft LS is endorsed. Final version is approved in R1-2306233.

Agreement

Indication of UTO-UCI by CG PUSCHs associated to a CG configuration, is enabled by configuration of an RRC parameter.

FFS on whether/how to extend to multiple CG configurations

Agreement

For a CG configuration with UTO-UCI indication enabled, to determine the indicated CG PUSCH by a UTO-UCI indication, consider the following options for further down-selection:

· Option A-1a:

o Configure the RRC parameter UTO_period.

§ FFS range value of UTO_period

· Alt-1: values in time unit (e.g., XR traffic periodicity)

· Alt-2: one or multiple of CG periodicity given by integer values (n=1, 2, ..)

o The starting time of the first period of UTO periodicity starts at the same as starting time of the first period of the CG configuration and ends after UTO_period. The next UTO period(s) are followed after the first UTO period.

o A transmitted CG PUSCH that is confined within a UTO period, carries UTO-UCI that is applicable to the CG PUSCH TOs within the UTO period.

· Option A-2a:

o Configure the RRC parameter UTO_period.

§ FFS range value of UTO_period

· Alt-1: values in time unit (e.g., XR traffic periodicity)

· Alt -2: one or multiple of CG periodicity given by integer values (n=1, 2, ..)

o Configure the RRC parameter UTO_offset.

§ FFS range value of UTO_offset

o A transmitted CG PUSCH that is confined within a UTO period, carries UTO-UCI that is applicable to the CG PUSCH TOs within the UTO period and after UTO_offset from the end of the transmitted CG PUSCH.

· Option B-a:

o Configure the RRC parameter UTO_period.

§ FFS range value of UTO_period

· Alt-1: values in time unit (e.g., XR traffic periodicity)

· Alt -2: one or multiple of CG periodicity given by integer value (n=1, 2, ..)

o UTO_offset is the offset value.

§ Alt-1: UTO_Offset is provided by configuration.

· FFS range value of UTO_offset

§ Alt-2: UTO_Offset = 0

o A transmitted CG PUSCH carries UTO-UCI that is applicable to the valid CG PUSCH TOs that are confined within UTO_period starting with UTO_offset from the end of the transmitted CG PUSCH.

· Option B-b2:

o Configure the RRC parameter Nu (Nu is the size of bit-map)

§ FFS range value of Nu

o UTO_offset is the offset value.

§ Alt-1: UTO_Offset is provided by configuration.

· FFS range value of UTO_offset

§ Alt-2: UTO_Offset = 0

o A transmitted CG PUSCH, carries UTO-UCI that is applicable to the Nu consecutive and valid CG PUSCH TOs, starting with UTO_offset from the end of the transmitted CG PUSCH.

· FFS on whether/how to extend to multiple CG configurations

Final summary in R1-2306089.

RAN1#114

9.8 XR Enhancements for NR

Please refer to RP-230786 for detailed scope of the WI. Rapporteur to provide initial input on higher layer signalling under agenda item 9.9. For input on higher layer signalling from any other source, please include it as part of your tdoc to relevant sub-agenda items. No discussion on ‘resumption of PDCCH monitoring after NACK’ in RAN1#114 (RP-231483).

[114-R18-XR] – Sorour (Ericsson)

Email discussion on XR

- To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

R1-2308028 Work Plan for Rel-18 WI on XR Enhancements for NR Nokia, Qualcomm (Rapporteurs), Ericsson (RAN1 FL)

R1-2307940 Initial higher layer parameters for Rel-18 XR enhancements Qualcomm Incorporated

R1-2308668 Summary of discussions on RRC parameters for Rel-18 XR WI Moderator (Qualcomm)

9.8.11 XR-specific capacity enhancements

From AI 5

R1-2306379 LS on new DRX cycles in rational numbers RAN2, Qualcomm

Decision: Discussion to be handled in agenda item 9.8.1. Moderator: Huilin (Qualcomm)

From Friday session

R1-2308653 Draft Reply LS on new DRX cycles in rational numbers Qualcomm

Decision: The draft response LS to R1-2306379 is endorsed. Final LS is approved in R1-2308654.

R1-2306403 Discussions on XR-specific capacity enhancements New H3C Technologies Co., Ltd.

R1-2306427 XR-specific capacity enhancements FUTUREWEI

R1-2306526 Discussion on CG enhancements for XR capacity Huawei, HiSilicon

R1-2306607 Capacity Enhancements for XR Ericsson

R1-2306628 Discussion on XR capacity enhancement techniques Panasonic

R1-2306659 Discussion on XR-specific capacity enhancements Spreadtrum Communications

R1-2306698 Discussion on XR-specific capacity enhancements Honor

R1-2306764 Discussion on XR specific capacity enhancements vivo

R1-2306918 Remaining Issues on XR specific capacity enhancements Sony

R1-2307101 Design of Multiple CG Occasions and unused CG occasion feedback CATT

R1-2307115 Discussion on XR-specific capacity enhancements NEC

R1-2307141 Discussion on XR specific capacity enhancements ZTE, Sanechips

R1-2307209 Discussion on XR-specific capacity enhancements CMCC

R1-2308202 XR-specific capacity enhancements Apple (rev of R1-2307292)

R1-2307398 Discussion on XR-specific capacity enhancements xiaomi

R1-2307405 On XR-specific capacity enhancements KT Corp.

R1-2307485 Discussion on XR specific capacity improvement enhancements NTT DOCOMO, INC.

R1-2307574 Discussion on XR specific capacity enhancements OPPO

R1-2307597 XR specific capacity enhancements TCL

R1-2307612 XR-specific capacity enhancements Nokia, Nokia Shanghai Bell

R1-2307692 Capacity enhancements for XR Samsung

R1-2307771 On XR-specific capacity enhancements techniques Google Inc.

R1-2307794 Discussion on XR-specific capacity enhancements LG Electronics

R1-2307815 XR-related CG Enhancements Lenovo

R1-2307819 Remaining issues on UTO-UCI content and reporting Sharp (Late submission)

R1-2307820 Discussion on XR-specific capacity enhancements InterDigital, Inc.

R1-2307866 Discussion on XR specific capacity enhancements CAICT

R1-2307941 Remaining Issues on Capacity Enhancement Techniques for XR Qualcomm Incorporated

R1-2308063 XR capacity enhancements MediaTek Inc.

R1-2308331 Moderator Summary#1 - XR Specific Capacity Improvements Moderator (Ericsson)

From Tuesday session

Agreement

Configure the RRC parameter Nu (Nu is the size of bit-map)

FFS range value of Nu

UTO_offset is the offset value.

Alt-1: UTO_Offset is provided by configuration.

FFS range value of UTO_offset

Alt-2: UTO_Offset = 0

A transmitted CG PUSCH, carries UTO-UCI that is applicable to the Nu consecutive and valid CG PUSCH TOs, starting with UTO_offset from the end of the transmitted CG PUSCH.

FFS on whether/how to extend to multiple CG configurations.

Strong concerns have been raised on the above proposal in terms of benefit and UE complexity by CATT, ZTE, Huawei, Apple, MTK, and Google.

Agreement

When UTO-UCI and HARQ-ACK are jointly encoded, HARQ-ACK bit sequence is concatenated after UTO-UCI bit sequence, by reusing the same mechanism adopted for joint encoding of CG-UCI and HARQ-ACK.

Conclusion

There is no consensus on the following proposal:

Introduce a new RRC parameter UTO-UCI-Multiplexing (similar to cg-UCI-Multiplexing) to enable/disable joint coding of HARQ-ACK and UTO-UCI in a CG PUSCH with the UTO-UCI.

Conclusion

For Type-1 and Type-2 multi-PUSCH CG configuration, Type-A repetition is NOT supported in Rel-18.

R1-2308332 Moderator Summary#2 - XR Specific Capacity Improvements Moderator (Ericsson)

From Thursday session

Agreement

For a multi-PUSCH CG configuration, the range value of the higher layer parameter indicating number of consecutive slots (N in previous agreements) is:

Max value=16 or 32

Up to UE capability

Min value=2

Agreement

For a CG configuration with UTO-UCI indication enabled:

For the range value for the RRC parameter Nu (Nu is the size of bit-map): (3, …, 8).

Conclusion

There is no consensus to introduce RRC parameter UTO_offset. This over-rides earlier RAN1 agreements.

R1-2308333 Moderator Summary#3 - XR Specific Capacity Improvements Moderator (Ericsson)

R1-2308334 Moderator Summary#4 - XR Specific Capacity Improvements Moderator (Ericsson)

From Friday session

Conclusion

Extending the UTO_UCI indication by CG PUSCH(s) of a CG configuration to CG PUSCH(s) of other CG configuration(s) is not supported in Rel-18.

Agreement

The following TP with stage 2 description for physical layer enhancements is endorsed in principle for TS 38.300. Send an LS to RAN2.

-----------------< Start of TP>--------------------

16.X.4 Capacity

16.X.4.1 Physical Layer Enhancements

The following enhancements for configured grant-based PUSCH transmission are introduced:

- Support of multiple CG PUSCH transmission occasions within a single period of a CG configuration

- Indication of unused CG PUSCH occasion(s) of a CG configuration with Uplink Control Information multiplexed in CG PUSCH transmission of the CG configuration.

-----------------< End of TP>--------------------

R1-2308637 Draft LS on stage 2 description for physical layer enhancements for XR Nokia

Decision: The draft LS is endorsed. Final LS is approved in R1-2308659.

Agreement

Select one of the following options:

· Option 1: Introduce a new capability to indicated maximum number of multi-PUSCH CG configurations (at least 2) per BWP of a serving cell and across all serving cells

o FG 50-1 as pre-requisite.

o FG 11-9 NOT as pre-requisite

· Option 2: Introduce a new capability to indicated maximum number of multi-PUSCH CG configurations (at least 2) per BWP of a serving cell and across all serving cells. The maximum number should not exceed the corresponding maximum number of CG configurations indicated by FG 11-9.

o FG 50-1 as pre-requisite.

o FG 11-9 as pre-requisite

· Option 3: Maximum number of multi-PUSCH CG configuration per BWP of a serving cell is one.

Final summary in R1-2308613.

RAN1#114-bis

8.6 Maintenance on XR Enhancements for NR

[114bis-R18-XR] Email discussion on XR – Sorour (Ericsson)

- To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

R1-2309081 PDCCH monitoring resumption after NACK vivo

From AI 5

R1-2308825 Reply LS on XR capacity enhancements RAN2, MediaTek

Decision: RAN2 requires RAN1 input on HARQ process ID formula and definition of an invalid CG PUSCH. Discussion on response LS to be handled in agenda item 8.6. Moderator: Umut (MediaTek).

R1-2310501 Draft Reply LS on XR capacity enhancements MediaTek

Wednesday decision: The draft LS is endorsed. Final version is approved in R1-2310502.

8.6.11 XR-specific capacity enhancements

R1-2308882 Maintenance of CG enhancements for XR capacity Huawei, HiSilicon

R1-2308936 Discussion on remaining issues of XR-specific capacity enhancements FUTUREWEI

R1-2308992 Remaining issues on XR-specific capacity enhancements Spreadtrum Communications

R1-2309082 Remaining issue on XR specific capacity enhancements vivo

R1-2309180 Discussion on remaining issues of XR ZTE, Sanechips

R1-2309273 Remaining issues on XR-specific capacity enhancements NEC

R1-2309297 XR-specific capacity enhancements Nokia, Nokia Shanghai Bell

R1-2309304 Remaining issues on XR-specific capacity enhancements LG Electronics

R1-2309382 Maintenance issues on XR Samsung

R1-2309463 Remaining issues on XR-specific capacity enhancements xiaomi

R1-2309533 Design of Multiple CG Occasions and unused CG occasion feedback CATT

R1-2309620 Discussion on XR specific capacity enhancements OPPO

R1-2309678 Maintenance on XR enhancements for NR CMCC

R1-2309732 XR specific capacity enhancements TCL

R1-2309788 Remaining issues on UTO-UCI and HARQ-ACK collision handling Sharp

R1-2309840 Remaining issues in XR-specific capacity enhancements Apple

R1-2309908 Remaining Issues on XR capacity enhancements Sony

R1-2309939 Remaining issues on XR-specific capacity enhancements InterDigital, Inc.

R1-2310002 Remaining issues on XR enhancements MediaTek Inc.

R1-2310148 Maintenance on XR Enhancements Qualcomm Incorporated

R1-2310255 On Maintenance of XR enhancements for NR Ericsson

R1-2310424 Moderator Summary#1 - Maintenance of XR Enhancements Moderator (Ericsson)

From Tuesday session

Agreement

· Adopt TP1-1 below for Clause 6.1 of 38.214:

6.1 UE procedure for transmitting the physical uplink shared channel

************** Unchanged parts omitted**************

When the UE is configured dl-OrJointTCI-StateList or ul-TCI-StateList, the UE shall perform PUSCH transmission corresponding to a Type 1 configured grant or a Type 2 configured grant or a dynamic grant according to the spatial relation, if applicable, with a reference to the RS for determining UL Tx spatial filter. The RS is determined based on an RS configured with qcl-Type set to 'typeD' of the indicated TCI-State or an RS in the indicated TCI-UL-State. The reference RS in the indicated TCI-State can be a CSI-RS resource in a NZP-CSI-RS-ResourceSet configured with higher layer parameter repetition, or a CSI-RS resource in an NZP-CSI-RS-ResourceSet configured with higher layer parameter trs-Info. The reference RS in the indicated TCI-UL-State can be a CSI-RS resource in a NZP-CSI-RS-ResourceSet configured with higher layer parameter repetition, a CSI-RS resource in an NZP-CSI-RS-ResourceSet configured with higher layer parameter trs-Info, an SRS resource in an SRS resource set with the higher layer parameter usage set to 'beamManagement', or SS/PBCH block associated with the same or different PCI from the PCI of the serving cell. When [nrofSlots_InCGperiod] is configured for Type 1 configured grant or Type 2 configured grant, HARQ process ID for the K^th (1 < K ≤ [nrofSlots_InCGperiod]) valid configured PUSCH grant is determined as in clause 5.4.1 of [10, TS 38.321], excluding invalid configured PUSCH grant(s) that are not transmitted due to collision with the DL symbol(s) indicated by tdd-UL-DL-ConfigurationCommon or tdd-UL-DL-ConfigurationDedicated if provided, or a symbol(s) of an SS/PBCH block with index provided by ssb-PositionsInBurst as described in clause 11.1 of [6, TS 38.213].

************** Unchanged parts omitted**************

*Reason for change:*	For determination of HARQ process ID for a multi-PUSCHs CG, the current specifications refer to the procedures in clause 11.1 of 38.213 which includes cases corresponding to collision with dynamic as well as semi-static transmissions or symbol direction indications. It is important to determine whether a CG PUSCH TO is valid or invalid for HARQ process ID determination of a multi-PUSCHs CG. In the corresponding agreements, it was clarified by the following Note the cases which are relevant for determining valid/invalid CG PUSCH TOs for HARQ process ID determination: Note: A configured CG PUSCH is invalid if the CG PUSCH is dropped due to collision with DL symbol(s) indicated by tdd-UL-DL-ConfigurationCommon or tdd-UL-DL-ConfigurationDedicated or SSB. Otherwise, it is valid. Hence, it should be clarified which collision cases in clause 11.1 are relevant for this purpose.

*Summary of change:*	Add description in clause 6.1 that for the procedures in clause 11.1, the CG PUSCH TO collision with DL symbol(s) indicated by tdd-UL-DL-ConfigurationCommon or tdd-UL-DL-ConfigurationDedicated or SSB results in an invalid CG PUSCH TO.

*Consequences if not approved:*	The definition of an invalid CG PUSCH has not been clearly captured in the specifications and results in inconsistency for the associated HARQ process ID determination procedures.

· Adopt TP1-2 below for Clause 9.3.1 of 38.213:

9.3.1 UE procedure for reporting UTO-UCI

If the UE is provided nrof_UTO_UCI with value equal to in configuredGrantConfig of a CG-PUSCH configuration, the UE multiplexes UTO-UCI represented by a bitmap of bits in each CG-PUSCH transmission for the CG-PUSCH configuration.

The bits of UTO-UCI, , have a one-to-one mapping to subsequent CG-PUSCH TOs in ascending order of start time. For unpaired spectrum operation, the subsequent CG-PUSCH TOs exclude invalid ones where a UE does not transmit a PUSCH due to collision of the PUSCH with the DL symbol(s) indicated by tdd-UL-DL-ConfigurationCommon or tdd-UL-DL-ConfigurationDedicated if provided, or a symbol(s) of an SS/PBCH block with index provided by ssb-PositionsInBurst based on the procedures in Clause 11.1. A bit value of ‘0’ indicates that the UE may transmit CG-PUSCH, and a bit value of ‘1’ indicates that the UE will not transmit CG-PUSCH, in a corresponding CG-PUSCH TO. When the UE indicates by UTO-UCI a value of ‘1’ for a CG-PUSCH TO, the UE continues to indicate the value of ‘1’ for the CG-PUSCH TO by UTO-UCI multiplexed in subsequent CG-PUSCH transmissions, and the UE does not transmit CG-PUSCH in the CG-PUSCH TO.

*Reason for change:*	For UTO-UCI indication for a configured grant, the current specifications refer to the procedures in clause 11.1 of 38.213 which includes cases corresponding to collision with dynamic as well as semi-static transmissions or symbol direction indications. It is important to determine whether a CG PUSCH TO is valid or invalid since the UTO-UCI indication is applicable only to valid CG PUSCH TOs. In the corresponding agreements, it was clarified by the following Note the cases which are relevant for determining valid/invalid CG PUSCH TOs for UTO-UCI indication: Note: A configured CG PUSCH is invalid if the CG PUSCH is dropped due to collision with DL symbol(s) indicated by tdd-UL-DL-ConfigurationCommon or tdd-UL-DL-ConfigurationDedicated or SSB. Otherwise, it is valid. Hence, it should be clarified which collision cases in clause 11.1 are relevant for this purpose.

*Summary of change:*	Add description in clause 9.3.1 that for the procedures in clause 11.1, the CG PUSCH TO collision with DL symbol(s) indicated by tdd-UL-DL-ConfigurationCommon or tdd-UL-DL-ConfigurationDedicated or SSB results in an invalid CG PUSCH TO.

*Consequences if not approved:*	The definition of an invalid CG PUSCH has not been clearly captured in the specifications and results in inconsistency for the associated UTO-UCI indication procedures.

Agreement

Rel-18 multi-PUSCH CG is not supported for operation on shared spectrum.

· Capture the above in description of RAN1 higher layer parameter list for nrofSlots_InCGperiod

Agreement

· Adopt TP4-1 below for Clause 6.3.2.4.1 of 38.212:

6.3.2.1.4 HARQ-ACK and CG-UCI/UTO-UCI

If the higher layer parameter nrof_UTO_UCI is configured, the procedure in this clause 6.3.2.1.4 applies by replacing CG-UCI with UTO-UCI in all the notations and texts, and replacing "When higher layer parameter cg-UCI-Multiplexing is configured" with "When UTO-UCI and HARQ-ACK have the same priority index and are jointly encoded and transmitted on a PUSCH".

*************** unchanged omitted *********************

*Reason for change:*	The procedures in clause 6.3.2.1.4 for CG-UCI can be reused for UTO-UCI. However, the current specification does not clarify that the procedure is this clause is applicable when UTO-UCI and HARQ-ACK have the same priority and are jointly encoded.

*Summary of change:*	Clarify that the procedures in clause 6.3.2.1.4 are applicable when UTO-UCI and HARQ-ACK have the same priority and are jointly encoded.

*Consequences if not approved:*	Inconsistent and ambiguous UE behaviour

Agreement

· Adopt TP5-1 below for Clause 6.3.2.4.1 of 38.212:

6.3.2.4.1 UCI encoded by Polar code

If the higher layer parameter nrof_UTO_UCI is configured, the procedures in this clause and the clauses it refers to apply by replacing CG-UCI with UTO-UCI in all the notations and texts, when applicable.

6.3.2.4.1.1 HARQ-ACK

For HARQ-ACK transmission on PUSCH not using repetition type B with UL-SCH and if numberOfSlotsTBoMS is not present in the resource allocation table, or if numberOfSlotsTBoMS is present in the resource allocation table and the value of numberOfSlotsTBoMS in the row indicated by the Time domain resource assignment field in DCI is equal to 1, the number of coded modulation symbols per layer for HARQ-ACK transmission, denoted as , is determined as follows:

****************** unchnaged omitted ***********************

*Reason for change:*	The maximum length of UTO-UCI bit sequence is 8, which is not larger than 11. Hence, polar code is not applicable to UTO-UCI when it is not jointly encoded with HARQ-ACK. However, when UTO-UCI is jointly encoded with HARQ-ACK, depending on the size of HARQ-ACK code book, the UTO-UCI and HARQ-ACK sequences together may result in a code book with a size larger than 11 bits. In this case Polar codes should be applied for encoding. Currently, joint encoding of UTO-UCI and HARQ-ACK with Polar code is missing from the specification.

*Summary of change:*	Include joint encoding of UTO-UCI and HARQ-ACK with Polar code when applicable.

*Consequences if not approved:*	Unspecified UE behaviour for jointly encoding UTO-UCI and HARQ-ACK with more than 11 bits.

R1-2310425 Moderator Summary#2 - Maintenance of XR Enhancements Moderator (Ericsson)

From Wednesday session

Agreement

· Adopt TP3-1 below for Clause 6.3.2.1.3A of 38.212:

*Reason for change:*	In TS 38.212, there are two “given by clause x.x of [5, TS 38.213]” in Clause 6.3.2.1.3A and Clause 6.3.2.1.5. As the corresponding clause has been updated in TS 38.213, the incomplete parts in TS 38.212 should be fixed.

*Summary of change:*	11 Fix the two incomplete clause references of TS 38.213 in TS 38.212.

*Consequences if not approved:*	The references in specifications are unclear
6.3.2.1.3A UTO-UCI For UTO-UCI bits transmitted on a CG PUSCH when the higher layer parameter nrof_UTO_UCI is configured, the UTO-UCI bit sequence is determined as follows: 12 - set for and , where is provided by nrof_UTO_UCI, and the UTO-UCI bit sequence is given by clause ~~x.x~~9.3.1 of [5, TS 38.213]. ****************** unchnaged text omitted *************************** 6.3.2.1.5 UCI with different priority indexes If the higher layer parameter nrof_UTO_UCI is configured, the procedure in this clause 6.3.2.1.5 applies by replacing CG-UCI with UTO-UCI in all the notations and texts, and replacing "is given by Table 6.3.2.1.3-1 mapped in the order from upper part to lower part" with "is given by clause ~~x.x~~9.3.1 of [5, TS 38.213]". ****************** unchnaged text omitted ***************************

Agreement

· Adopt TP4-2 below for Clause 6.3.2.7 of 38.212:

Reason for change:

The procedures in clause 6.3.2.7 for CG-UCI can be reused for UTO-UCI. However, the following highlighted case described in this clause is not applicable to UTO-UCI since UTO-UCI has the same priority as the CG-PUSCH that is multiplexed in:

If uci-MuxWithDiffPrio is configured, and HARQ-ACK bits associated with priority index 0, HARQ-ACK bits associated with priority index 1 and/or CG-UCI associated with priority index 1, and CSI part 1 if any are transmitted on a PUSCH,

- if CSI part 1 is also transmitted on the PUSCH and the PUSCH is associated with priority index 1, the coded UCI bits are multiplexed onto PUSCH according to the procedures in Clause 6.2.7 by taking HARQ-ACK with priority index 1 as HARQ-ACK, and taking HARQ-ACK with priority index 0 as CSI part 2;

- otherwise, the coded UCI bits are multiplexed onto PUSCH according to the procedures in Clause 6.2.7 by taking HARQ-ACK with priority index 1 if any as HARQ-ACK, taking CG-UCI associated with priority index 1 if any as CG-UCI, taking HARQ-ACK with priority index 0 as CSI part 1, and taking CSI part 1 as CSI part 2 if CSI part 1 is also transmitted on the PUSCH and the PUSCH is associated with priority index 0.

The inconsistency can be resolved by considering applicable cases for UTO-UCI when the corresponding CG-UCI procedures can be reused.

Summary of change:

Add “when applicable” to the condition to resue the CG-UCI procedures for UTO-UCI.

Consequences if not approved:

Inconsistent and ambiguous UE behaviour

6.3.2.7 Multiplexing of coded UCI bits with different priority indexes to PUSCH

If the higher layer parameter nrof_UTO_UCI is configured, the procedure in this clause 6.3.2.7 applies by replacing CG-UCI with UTO-UCI in all the notations and texts, when applicable.

******************** unchnaged text omitted *****************************

Final summary in R1-2310426.

RAN1#115

8.6 Maintenance on XR Enhancements for NR

[115-R18-XR] – Sorour (Ericsson)

Email discussion on XR

- To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

8.6.11 XR-specific capacity enhancements

R1-2310832 Remaining issues of XR-specific capacity enhancements FUTUREWEI

R1-2310995 Discussion on remaining issues of XR ZTE, Sanechips

R1-2311104 Remaining issue on XR specific capacity enhancements vivo

R1-2311273 Remaining issues on XR specific capacity enhancements OPPO

R1-2311349 Design of Multiple CG Occasions and unused CG occasion feedback CATT

R1-2311408 Remaining issues on XR-specific capacity enhancements xiaomi

R1-2311489 Remaining issues on XR-specific capacity enhancements CMCC

R1-2311533 Remaining issues on XR-specific capacity enhancements InterDigital, Inc.

R1-2311628 Discussion on maintenance on XR enhancements NTT DOCOMO, INC.

R1-2311691 Remaining issues in XR-specific capacity enhancements Apple

R1-2311732 XR-specific capacity enhancements Nokia, Nokia Shanghai Bell

R1-2311851 Remaining issues on XR Samsung

R1-2311897 Remaining issues on XR-specific capacity enhancements LG Electronics

R1-2311905 On Maintenance of XR enhancements for NR Ericsson

R1-2311953 Clarification on UTO-UCI and HARQ-ACK multiplexing on PUSCH Sharp

R1-2312043 Maintenance on XR Enhancements Qualcomm Incorporated

R1-2312217 Maintenance of CG enhancements for XR capacity Huawei, HiSilicon

R1-2312385 Moderator Summary#1 - Maintenance of XR Enhancements Moderator (Ericsson)

From Tuesday session

Agreement

Endorse the following TP for TS38.214.

*Reason for change:*	1) Repetition and TB processing over multiple slots are not supported for multi-PUSCHs CG. The current description can be improved to address each case independently. 2) The time domain allocation across slots when cg-nrofSlots or nrofSlots_InCGperiod for NR-U CG and multi-PUSCH CG, respectively, can be improved to clearly specify the same time domain allocation is used across the slots.

*Summary of change:*	1) Describe that repetition is not supported for multi-PUSCH CG and TBoMs is not supported for multi-PUSCH CG. 2) Clarify that the same SLIV across slots is used when cg-nrofSlots or nrofSlots_InCGperiod is configured.

*Consequences if not approved:*	Inconsistent specifications.
6.1.2.3 Resource allocation for uplink transmission with configured grant <<< unchanged omitted>>> For PUSCH transmissions with a Type 1 or Type 2 configured grant, the number of (nominal) repetitions K to be applied to the transmitted transport block is provided by the indexed row in the time domain resource allocation table if numberOfRepetitions is present in the table; otherwise K is provided by the higher layer configured parameters repK. For a configuredGrantConfig, If if a UE is configured with higher layer parameter [nrofSlots_InCGperiod], ~~in a configuredGrantConfig,~~ the UE does not support repetition and does not support ~~neither repetition of the transmitted transport block nor~~ the TB processing over multiple slots ~~is supported~~ for the configuredGrantConfig. <<< unchanged omitted>>> A set of allowed periodicities P are defined in [12, TS 38.331]. The higher layer parameter cg-nrofSlots, provides the number of consecutive slots allocated within a configured grant period. The higher layer parameter cg-nrofPUSCH-InSlot provides the number of consecutive PUSCH allocations within a slot, where the first PUSCH allocation follows the higher layer parameter timeDomainAllocation for Type 1 PUSCH transmission or the higher layer configuration according to [10, TS 38.321], and UL grant received on the DCI for Type 2 PUSCH transmissions, and the remaining PUSCH allocations have the same length and PUSCH mapping type, and are appended following the previous allocations without any gaps. The higher layer parameter [nrofSlots_InCGperiod] provides the number of consecutive slots allocated within a configured grant period. The same combination of start symbol and length and PUSCH mapping type repeats over the consecutively allocated slots if cg-nrofSlots or [nrofSlots_InCGperiod] is configured. If [nrofSlots_InCGperiod] is configured, the PUSCH allocation in each consecutive slot follows the higher layer parameter timeDomainAllocation for Type 1 PUSCH transmission or the higher layer configuration according to [10, TS 38.321], and UL grant received in the DCI for Type 2 PUSCH transmissions. If a UE is configured with higher layer parameter [nrofSlots_InCGperiod] in a configuredGrantConfig, the UE does not expect to be configured with cg-nrofSlots and cg-nrofPUSCH-InSlot in the configuredGrantConfig. <<< unchanged omitted>>>

Conclusion

RAN1 confirms the HARQ process ID determination for multi-PUSCH per CG period as in RAN2 running CR R2-2309316.

Agreement

· Remove the square bracket in in TS 38.214.

· Remove a redundant minus operation in the equation in TS 38.214.

Conclusion

When UE is configured with multiple CG configurations, including multi-PUSCH CG configuration(s), the existing ConfiguredGrantConfigIndex is used to indicate the index of one of multiple Configured Grant configurations in one BWP.

Conclusion

When UE is configured with multiple CG configurations, including multi-PUSCH CG configuration(s), joint release of multiple CG configurations is supported as legacy.

· The above feature is subject to UE capability.

R1-2312386 Moderator Summary#2 - Maintenance of XR Enhancements Moderator (Ericsson)

From Friday session

Agreement

Endorse the following TP for Clause 6.1 of TS38.214.

*Reason for change:*	1) The current description of “K^th (1 < K ≤ [nrofSlots_InCGperiod]) valid configured PUSCH grant” makes an incorrect index counting in a CG periodicity is invalid. In addition, this index K is redundant given it is not used in other places over RAN1 specifications. 2) In the current RAN1 Rel-18 spec, valid/invalid configured PUSCH grant is defined from invalid configured PUSCH perspective. That makes it inevitable to propagate this definition to the first configured PUSCH grant, which goes beyond the applicability of valid/invalid configured PUSCH grant in HPID determination in RAN2 specification TS38.321.

*Summary of change:*	1) Change “the K^th (1 < K ≤ [nrofSlots_InCGperiod]) valid configured PUSCH grant” to “the first configured PUSCH grant and each subsequent valid configured PUSCH grant within a periodicity of the configuration”. 2) Define valid/invalid configured PUSCH grant from perspective of valid configured PUSCH grant, instead of invalid configured PUSCH grant.

*Consequences if not approved:*	Potentially incorrect applicability of HPID determination and inconsistency between RAN1 specification and RAN2 specification.
6.1 UE procedure for transmitting the physical uplink shared channel ************ Unchanged parts omitted************ When [nrofSlots_InCGperiod] is configured for Type 1 configured grant or Type 2 configured grant, HARQ process ID for the ~~K^th (1 < K ≤ [nrofSlots_InCGperiod])~~ first configured PUSCH grant and each subsequent valid configured PUSCH grant within a periodicity of the configuration is determined as in clause 5.4.1 of [10, TS 38.321], where a valid configured PUSCH grant is the configured PUSCH grant that is not collided ~~excluding invalid~~ ~~configured PUSCH grant that are not transmitted due to collision~~ with the DL symbol(s) indicated by tdd-UL-DL-ConfigurationCommon or tdd-UL-DL-ConfigurationDedicated if provided, or and is not collided with a symbol(s) of an SS/PBCH block with index provided by ssb-PositionsInBurst as described in clause 11.1 of [6, TS 38.213]. ************ Unchanged parts omitted************

Final summary in R1-2312387.